Hi Christian, If you think it makes sense to standardize something like this, I can work with you on getting an OSGi RFP started on this topic. Once there is some initial content, we can put it on https://github.com/osgi/design for further feedback.
Cheers, David On 9 October 2013 10:43, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Christian, > > as blueprint is part of OSGi specification, it makes sense to be introduce a > new "optional" status for bundle that use blueprint. > > Let see what the others think about that. > > Regards > JB > > On 10/09/2013 11:39 AM, 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? 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 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 >> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > _______________________________________________ > 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
