调试OSGi组件激活/停用问题

Question

我试图调试一个问题，这个问题似乎是由我的一个OSGi组件在框架关闭期间的奇怪行为引起的。

当我试图通过调用

context.getBundle(0).shutdown()

我的组件被停用，但由于某种原因，它被重新激活，然后再次停用。第二个激活/停用周期会导致一些奇怪的行为，因为组件注册了一个“UI容器”，这会导致应用程序的UI在关闭期间闪烁。

我的问题是什么会导致第二个激活/停用周期？

我正在使用声明性服务Maven、ApacheFelix和SCR插件。

下面的链接指向停用/重新激活/停用方法的堆栈跟踪，这些方法在下面的回答中有要求：

停用堆栈跟踪

重新激活堆栈跟踪

停用堆栈跟踪

Answer 1

我写一个答案，因为它比评论长（它可能是答案）：

• ConfigAdmin在DS和包含组件的捆绑包之前停止
• 当ConfigAdmin停止时，它会触发一个事件，说明配置不再可用
• 您的组件是以不需要配置的方式配置的，因此它会由于现有配置消失而停止，并在组件不需要配置时重新激活

若要了解是否存在这种情况，请在激活和停用功能中插入以下内容：

Thread.dumpStack();

然后将堆栈跟踪复制到您的问题中。

如果是这种情况，可以通过在组件上设置所需的配置策略来解决。

使现代化

我做了什么（你也可以做什么）来比较停用和重新激活的堆栈跟踪。你会在差异开始的地方找到有用的信息。

基于上传的堆栈跟踪：提供间接引用服务的组件被停用，然后再次激活。原因:

它的一个依赖项（引用消失），但另一个满足组件。

重新激活堆栈跟踪的有趣部分如下：

at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:972)
at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:134)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:1024)
at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:818)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:946)
at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:871)
at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1503)

如果可以，请为您的组件的激活功能添加断点。在重新激活期间，请参阅堆栈跟踪并执行以下操作：

at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:946)

请查看为什么源代码中的重新激活标志具有true值和RemvedService函数的serviceInformation参数的值。还可以在调试视图中找到，在堆栈跟踪的这一点上，您处于哪个组件中。因此，您将知道，哪个组件被重新激活，以及基于哪个服务引用。您可以将组件重新配置为仅连接唯一的服务引用。

我还将考虑编写邮件到FeliX邮件列表，以计算如果系统束处于停止状态，则不应重新激活组件的方式来重新激活标志。