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: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to