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