Hi Am 09.10.2013 um 06:15 schrieb Christian Schneider:
> 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. IIRC a FrameworkEvent.ERROR is sent for bundles failing to resolve or start ? Regards Felix > > 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 > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
