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 ;-) ) 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
