Great - I'll get you involved as well, JB. Cheers,
David On 9 October 2013 11:12, Jean-Baptiste Onofré <[email protected]> wrote: > I would be pleased to work on this RFP too. > > Regards > JB > > > On 10/09/2013 11:51 AM, David Bosschaert wrote: >> >> 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 >> > > -- > 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
