On 10/9/13 09:15 , 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.
Activator exceptions are not swallowed, they would generally be wrapped
and rethrown as BundleExceptions.
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.
To be clear, the spec is simply saying that since they are called
synchronously, they will hold up state transitions until they finish.
But regardless, yes, these are all mechanisms that can be used by
extenders to provide better diagnostics. I'd be loath to introduce
additional mechanisms into the framework that merely provide specialized
ways to do stuff you can already do.
Better diagnostics: +1
Extending the framework: -1 unless it is really compelling
-> richard
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
