On 9 oct. 2013, at 17:51, Richard S. Hall <[email protected]> wrote:
> > On 10/9/13 11:21 , Felix Meschberger wrote: >> Hi >> >> Am 09.10.2013 um 05:24 schrieb Richard S. Hall: >> >>> 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. >> Agreed, but how about this tangent : Allow extenders to hook into the >> Bundle.adapt(Class) method to expose extend state which then may expose >> extender information related to the bundle ? >> >> (Yes this is still requirements gathering, but I had to write down this idea >> flying through my head ;-) ) > > This is precisely why I was against the adapt() method ever being added to > the spec in the first place since it creates a secondary registry of > service-like objects. Why not just have an extender register a service that > has a getMoreInfo(Bundle) method on it? :-) > This is more or less how iPOJO introspection is working. We expose services (Declaration and Architecture) that let you get all the information you need. Regards, Clement > -> richard > >> >> Regards >> Felix >> >>>> I also think it would be nice to have a common api to get some >>>> diagnosis state for bundles. You could ask this api about a bundle id >>>> and it could return a list of exceptions provided by all extenders >>>> that processed the bundle. >>> I believe there are already examples of such diagnostic API in Felix' >>> SCR and iPOJO. It could make sense to standardize, but the question >>> would be how far could you go, since extenders can have wildly different >>> capabilities and purposes (e.g., extenders are only for DI). >>> >>> -> richard >>> >>>> I am currently working an a pax exam improvement to have an assertion >>>> like this but it would be a lot nicer if the OSGi framework would >>>> already provide such an API and if the DI framework could already add >>>> diagnostic infos. So the pax exam assertion could then just rely on >>>> the api and not care about all the technologies. >>>> >>>> Christian >>>> >>>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
