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
