You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sven Strohschein <no...@gmx.de> on 2012/01/29 18:56:13 UTC
Validation of OSGi bundles?
Hi,
I have built a small plugin system with OSGi. Every plugin-bundle
registers a PluginService. Now I would like to validate the
registered/started plugin bundles/services. For example I would like to
check if an icon is available within the bundle classpath.
I tried to implement a ServiceTracker which validates the bundle on
"ServiceTracker.addingService(...)" and when the validation is failed,
the validated bundle gets stopped via
"Bundle.stop(Bundle.STOP_TRANSIENT)". This does work in some cases, but
sometimes Felix throws a NullPointerException.
Maybe it is not the best solution to stop the bundles within a
ServiceTracker. Is there another way to implement a validation mechanizm?
Thank you in advance.
Here is the NullPointerException which is sometimes thrown by Felix.
ERROR: Bundle org.apache.felix.bundlerepository [26] EventDispatcher:
Error during dispatch. (java.lang.NullPointerException)
java.lang.NullPointerException
at
org.apache.felix.bundlerepository.impl.LocalRepositoryImpl.serviceChanged(LocalRepositoryImpl.java:71)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:449)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:460)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1009)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:333)
at
org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:157)
at
org.apache.felix.scr.impl.config.ConfiguredComponentHolder.enableComponents(ConfiguredComponentHolder.java:256)
at
org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:253)
at
org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
at
org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
at
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
at
org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4236)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Validation of OSGi bundles?
Posted by Sven Strohschein <no...@gmx.de>.
Hi,
I have now switched to the extender-pattern and it works very well.
Thank you for the support! :-)
Regards,
Sven S.
Am 30.01.2012 00:02, schrieb Marcel Offermans:
> Hello Sven,
>
> So your use case is that you have an application, that supports plugins, where every plugin:
>
> 1) is checked to make sure it contains certain resources on its classpath;
> 2) registers a PluginService if it does.
>
> I would use the extender pattern for this scenario, where every plugin would simply declare the class that implements the PluginService (and not declare an activator). Your extender can then first perform the checks of step 1 and then do step 2, or log some kind of error if it does not like what it sees.
>
> Greetings, Marcel
>
>
> On Jan 29, 2012, at 23:25 , Richard S. Hall wrote:
>
>> On 1/29/12 12:56, Sven Strohschein wrote:
>>> Hi,
>>>
>>> I have built a small plugin system with OSGi. Every plugin-bundle registers a PluginService. Now I would like to validate the registered/started plugin bundles/services. For example I would like to check if an icon is available within the bundle classpath.
>>>
>>> I tried to implement a ServiceTracker which validates the bundle on "ServiceTracker.addingService(...)" and when the validation is failed, the validated bundle gets stopped via "Bundle.stop(Bundle.STOP_TRANSIENT)". This does work in some cases, but sometimes Felix throws a NullPointerException.
>> It is considered bad practice to change the state of a bundle which is the subject of the event in a synchronous callback because typically the framework is in an awkward state at this point (usually holding locks). Somewhere in the spec, there are some words to this effect.
>>
>> Besides, you can't pull the rug out from underneath a bundle in the middle of it trying to do something like register a service.
>>
>>> Maybe it is not the best solution to stop the bundles within a ServiceTracker. Is there another way to implement a validation mechanizm?
>> I'm not sure. You might be able to do this in iPOJO by creating a custom handler that could validate component services and if they were valid annotate them with some specific "validated" service property. It wouldn't stop components from registering services, but it would make it easy for you to only look at valid services.
>>
>> Perhaps a simpler approach is to simply make all your conditions service properties if possible, so you can just query for their existence.
>>
>> -> richard
>>
>>> Thank you in advance.
>>>
>>>
>>> Here is the NullPointerException which is sometimes thrown by Felix.
>>>
>>> ERROR: Bundle org.apache.felix.bundlerepository [26] EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
>>> java.lang.NullPointerException
>>> at org.apache.felix.bundlerepository.impl.LocalRepositoryImpl.serviceChanged(LocalRepositoryImpl.java:71)
>>> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
>>> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
>>> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
>>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
>>> at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
>>> at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
>>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:449)
>>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:460)
>>> at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1009)
>>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:333)
>>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:157)
>>> at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.enableComponents(ConfiguredComponentHolder.java:256)
>>> at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:253)
>>> at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>>> at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
>>> at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
>>> at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
>>> at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
>>> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
>>> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
>>> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4236)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
>>> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
>>> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
>>> at java.lang.Thread.run(Thread.java:662)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Validation of OSGi bundles?
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Sven,
So your use case is that you have an application, that supports plugins, where every plugin:
1) is checked to make sure it contains certain resources on its classpath;
2) registers a PluginService if it does.
I would use the extender pattern for this scenario, where every plugin would simply declare the class that implements the PluginService (and not declare an activator). Your extender can then first perform the checks of step 1 and then do step 2, or log some kind of error if it does not like what it sees.
Greetings, Marcel
On Jan 29, 2012, at 23:25 , Richard S. Hall wrote:
> On 1/29/12 12:56, Sven Strohschein wrote:
>> Hi,
>>
>> I have built a small plugin system with OSGi. Every plugin-bundle registers a PluginService. Now I would like to validate the registered/started plugin bundles/services. For example I would like to check if an icon is available within the bundle classpath.
>>
>> I tried to implement a ServiceTracker which validates the bundle on "ServiceTracker.addingService(...)" and when the validation is failed, the validated bundle gets stopped via "Bundle.stop(Bundle.STOP_TRANSIENT)". This does work in some cases, but sometimes Felix throws a NullPointerException.
>
> It is considered bad practice to change the state of a bundle which is the subject of the event in a synchronous callback because typically the framework is in an awkward state at this point (usually holding locks). Somewhere in the spec, there are some words to this effect.
>
> Besides, you can't pull the rug out from underneath a bundle in the middle of it trying to do something like register a service.
>
>>
>> Maybe it is not the best solution to stop the bundles within a ServiceTracker. Is there another way to implement a validation mechanizm?
>
> I'm not sure. You might be able to do this in iPOJO by creating a custom handler that could validate component services and if they were valid annotate them with some specific "validated" service property. It wouldn't stop components from registering services, but it would make it easy for you to only look at valid services.
>
> Perhaps a simpler approach is to simply make all your conditions service properties if possible, so you can just query for their existence.
>
> -> richard
>
>>
>> Thank you in advance.
>>
>>
>> Here is the NullPointerException which is sometimes thrown by Felix.
>>
>> ERROR: Bundle org.apache.felix.bundlerepository [26] EventDispatcher: Error during dispatch. (java.lang.NullPointerException)
>> java.lang.NullPointerException
>> at org.apache.felix.bundlerepository.impl.LocalRepositoryImpl.serviceChanged(LocalRepositoryImpl.java:71)
>> at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
>> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
>> at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
>> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
>> at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
>> at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:449)
>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:460)
>> at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1009)
>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:333)
>> at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:157)
>> at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.enableComponents(ConfiguredComponentHolder.java:256)
>> at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:253)
>> at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
>> at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
>> at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
>> at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
>> at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
>> at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
>> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
>> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4236)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
>> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
>> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Validation of OSGi bundles?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/29/12 12:56, Sven Strohschein wrote:
> Hi,
>
> I have built a small plugin system with OSGi. Every plugin-bundle
> registers a PluginService. Now I would like to validate the
> registered/started plugin bundles/services. For example I would like
> to check if an icon is available within the bundle classpath.
>
> I tried to implement a ServiceTracker which validates the bundle on
> "ServiceTracker.addingService(...)" and when the validation is failed,
> the validated bundle gets stopped via
> "Bundle.stop(Bundle.STOP_TRANSIENT)". This does work in some cases,
> but sometimes Felix throws a NullPointerException.
It is considered bad practice to change the state of a bundle which is
the subject of the event in a synchronous callback because typically the
framework is in an awkward state at this point (usually holding locks).
Somewhere in the spec, there are some words to this effect.
Besides, you can't pull the rug out from underneath a bundle in the
middle of it trying to do something like register a service.
>
> Maybe it is not the best solution to stop the bundles within a
> ServiceTracker. Is there another way to implement a validation mechanizm?
I'm not sure. You might be able to do this in iPOJO by creating a custom
handler that could validate component services and if they were valid
annotate them with some specific "validated" service property. It
wouldn't stop components from registering services, but it would make it
easy for you to only look at valid services.
Perhaps a simpler approach is to simply make all your conditions service
properties if possible, so you can just query for their existence.
-> richard
>
> Thank you in advance.
>
>
> Here is the NullPointerException which is sometimes thrown by Felix.
>
> ERROR: Bundle org.apache.felix.bundlerepository [26] EventDispatcher:
> Error during dispatch. (java.lang.NullPointerException)
> java.lang.NullPointerException
> at
> org.apache.felix.bundlerepository.impl.LocalRepositoryImpl.serviceChanged(LocalRepositoryImpl.java:71)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4252)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3275)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:449)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.registerComponentService(AbstractComponentManager.java:460)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1009)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:333)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:157)
> at
> org.apache.felix.scr.impl.config.ConfiguredComponentHolder.enableComponents(ConfiguredComponentHolder.java:256)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:253)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:147)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:111)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:285)
> at
> org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:203)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4236)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:662)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org