Yepp, that was my understanding as well - today, troubleshooting can become quiet complex as there are soo many places to look at, especially if different extenders are used.
Carsten 2013/10/9 David Bosschaert <[email protected]> > On 9 October 2013 13:50, Richard S. Hall <[email protected]> wrote: > > On 10/9/13 08:42 , Christian Schneider wrote: > >> > >> On 09.10.2013 14:24, Richard S. Hall wrote: > >>> > >>> On 10/9/13 05:39 , Christian Schneider wrote: > >>>> > >>>> Nowadays dependency injection technologies like blueprint, ds and > spring > >>>> dm are used a lot in OSGi. All these have in common that they are > extender > >>>> based. So instead of using an activator you have an extender that > detects if > >>>> you use such a technology and initializes the bundle. > >>>> > >>>> Unfortunately this makes diagnosing the status of your system a lot > >>>> harder. A bundle can be active and still the blueprint context may > have > >>>> failed to create or the extender is even absent. The case of no > extender can > >>>> be nicely solved by capabilities which seem to be introduced in the > newest > >>>> spec proposals. > >>>> > >>>> What I have not yet seen is a common status and error reporting. I > have > >>>> written such a thing for karaf where the bundle status is combined > from the > >>>> OSGi bundle status + e.g. the blueprint status if the bundle uses > blueprint. > >>>> I also created a diag command that shows blueprint errors to make it > easier > >>>> to spot problems. > >>>> > >>>> Would it make sense to standardize this? Perhaps by allowing an > extender > >>>> to override the reported status of a bundle? > >>> > >>> > >>> No, I don't think such a mechanism makes sense. This is no longer the > >>> extender pattern any more. If you really want to do this as part of > your > >>> "extender", you can just provide a standard activator that extendee > bundles > >>> must use and this standard activator could do whatever it wanted to > fail > >>> activation if it so desired. This is how we had to do DI in OSGi > before you > >>> could get access to a bundle's context externally (a la Service > Binder). > >>> > >>> Creating some mechanism to create effectively implicit activators is > >>> going too far. > >>> > >> Yes probably it does not make sense to let the extender directly > influence > >> the bundle status. Still I think an extender should be involved in > >> determining the status of the bundle. Of course this can only happen if > the > >> extender is a little bit less decoupled from the bundle lifecycle than > right > >> now. > >> > >> So for example I could imagine that the resolver sees that the bundle > has > >> a requirement for a blueprint extender. So we could have an API were > >> providers of capabilities could register their initialization services. > For > >> blueprint this service would read the context xml and establish the > >> blueprint context. > >> The service could return the success or failure status. Then the > framework > >> could use this to determine the bundle state and also store the error > for > >> the common status reporting I mentioned below. > > > > > > 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. > > > > 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. > > > > 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. > > > > -> richard > > Well at this stage I think we're really talking about requirements. I > think one of the core requirements is to find out in a more standard > way whether a particular extender completed its work successfully. > > This may not require changes to the core framework, but a standard > approach on top of the framework, as is done with any of the > Enterprise specs might help IMHO... > > Cheers, > > David > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Carsten Ziegeler [email protected]
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
