On 09.10.2013 15:50, Richard S. Hall wrote:
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.
I checked the sources of felix. Yes the exception is wrapped and
rethrown. So it probably depends on how the bundle.start() method is
called. Still from a user point of view I had the impression that the
exception was swallowed.
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
I am of course open to other ways of providing better diagnostics. Do
you have an idea how it can be done without changes on the framework?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
