Just a point: be careful in the order of registration of the
SynchronousBundleListener.
For instance, each BlueprintContainer itself uses a
SynchronousBundleListener. So, if you register your own
SynchronousBundleListener after the blueprint container one, the
blueprint container can be destroyed before you got the event.
Regards
JB
On 10/09/2013 03:15 PM, Christian Schneider wrote:
On 09.10.2013 14:50, Richard S. Hall wrote:
Again, the extender can already do this with no extra support from the
framework, simply implement an activator that extendee bundles must
use. There is no reason to push more into the framework.
Using an activator is of course possible and it would indeed by nice if
the DI frameworks would at least optionally allow to explicitly call
their initialization routines.
Even for a normal activator the diagnostics are not really good though.
What I would like to have is that the framework captures exceptions
thrown by the activator and lets me query them. I think currently the
exceptions are swallowed by the framework. I think they do not even end
up in the log. At least I remember that I always have a try catch in my
start method to make sure I log the exception.
So while the Activator would be a good place to do DI initialization I
think it should not be the only possible place. The extender pattern is
quite popular and I think it makes sense to improve this pattern to
provide better diagnostics.
I found a nice article from Peter where he discusses the extender model:
http://blog.osgi.org/2007/02/osgi-extender-model.html
There he also mentions the
http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/SynchronousBundleListener.html.
I think the SynchronousBundleListener could be used to support better
diagnostics. The spec says that all listeners must succeed before the
bundle can go into the desired status. So we would just need to catch
and record exceptions from the listeners and provide an API to query them.
And trying to make this part of the resolve process is probably a
mistake anyway, since the resolve process is already complicated
enough. Technically, an extender could possibly implement something
similar to what you are saying with a resolver hook that filtered its
own extender capability if it felt that the extendee could not be
successfully initialized, thus the extendee would fail to resolve.
You are right. The resolver is probably the wrong place to put this.
Anyway if I understood it correctly then the resolver is involved when
the bundle goes into status resolved. So as I am interested in the
transition from resolved to active the resolver is probably the wrong
place.
However, I wouldn't make this a recommended approach because I am sure
it would make the resolve process harder to understand for the average
person, because they'd really have no idea why the resolve failed.
Well this may then also be a case where better diagnostics are required.
The case I look at when a bundle is processed by an extender is equally
difficult to understand by developers and more so by admins. So I think
this is exactly a reason why improved and standardized diagnostics are
required.
Christian
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
