Hi, sounds like a great idea, count me in (I can cover the DS part)
Carsten 2013/10/9 David Bosschaert <[email protected]> > Yes, I agree. > > The nice thing is that because all the RFPs and RFCs are now visible > to everyone at https://github.com/osgi/design we can get feedback from > the whole community. > > Cheers, > > David > > On 9 October 2013 11:24, Christian Schneider <[email protected]> > wrote: > > Hi David, > > > > sure I can help with the RFP. > > I hope we also get people from ds and spring dm on board as it makes most > > sense if we have a common solution. > > > > Christian > > > > > > On 09.10.2013 11:51, 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 > > > > > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > > > 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 > -- Carsten Ziegeler [email protected]
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
