On Tue, Aug 21, 2018 at 4:00 PM, Romain Manni-Bucau <[email protected]> wrote:
> Oki. So sounds inside an extension bundle the extension can access its own > beans too which is the case of config so sounds like we are good or > goodable ;). > > Btw which impl do you use to test? Any way to test at build time? > I test with an assembled set of OSGi bundles run directly using the bnd osgi test support. It's a real environment. I can provide a project that is my test bed for this work if you would like to see it. - Ray > > Le mar. 21 août 2018 21:58, Raymond Auge <[email protected]> a > écrit : > >> >> >> On Tue, Aug 21, 2018 at 3:09 PM, Romain Manni-Bucau < >> [email protected]> wrote: >> >>> >>> >>> Le mar. 21 août 2018 20:17, Raymond Auge <[email protected]> a >>> écrit : >>> >>>> >>>> >>>> On Tue, Aug 21, 2018 at 1:57 PM, Romain Manni-Bucau < >>>> [email protected]> wrote: >>>> >>>>> You can always add the package in se mode. But long story short a >>>>> beans.xml solution is still recommanded over annotated mode which kind of >>>>> failed by its spec. >>>>> >>>> >>>> Keeping the beans.xml is no harm (for OSGi CDI) provided the beans are >>>> added via the SPI also (is that an issue?) OSGi CDI will simply ignore the >>>> beans.xml (in portable extension bundles). >>>> >>>> The reason this is the case is that the OSGi CDI wants to be able to >>>> preserve the sanctity of the class spaces between bundles providing >>>> extensions and bundles providing the application beans. This way OSGi CDI >>>> doesn't have to operate at all on any classes of the portable extension >>>> bundles, it consumes the extension implementations as services, the >>>> services add the beans programmatically and the separate is nice and clean. >>>> >>> >>> Hmm, do I understand right osgi-cdi is not cdi but just a bean registry >>> where extensions can only add beans? If so this is completely broken and >>> breaks all the beauty of cdi extensions which are here first to collect and >>> mutate beans meta based on the scanning and not just a guice module >>> replacement. I hope I got it wrong but if not we need a way to support this >>> other ioc lightly and validated at build time. >>> >> >> Hmm, I want to say no! But I'm not sure I understand your concern. >> >> How to explain this simply. OSGi CDI Integration clearly distinguishes >> between portable extension bundles and application bundles (called simply >> CDI bundles). This separation allows for an ecosystem of portable >> extensions to exist as OSGi bundles without hackery of classloaders >> separately from CDI bundles and a complex environment where some CDI >> bundles (a framework can have as many CDI containers; 1:1 CDI bundles). >> >> In order to make this ecosystem resilient and stable under the dynamics >> of OSGi, portable extensions must provide only Extensions services (read >> OSGi services; this is seamless to plain CDI code by leveraging the power >> of Service Loader Mediator which handles this transparently). >> >> Now, portable extensions in this model still have the full power of the >> SPI. Only that the "automatic" ability include beans via the beans.xml is >> eliminated to simply the class loading ugliness that would require. >> >> However, inside the CDI bundle, everything looks and works like normal >> CDI, having it's beans processed by extensions, etc plus the ability to >> properly consume and react to OSGi services and configuration. >> >> I hope that clarified enough. >> - Ray >> >> >>> >>>> >>>>> >>>>> Le mar. 21 août 2018 19:51, John D. Ament <[email protected]> a >>>>> écrit : >>>>> >>>>>> I would have to double check in SE mode but I think the archive would >>>>>> be ignored without a beans.xml, at least with weld. >>>>>> >>>>> >>>> Like I said, we could keep the beams.xml it's not a problem. >>>> >>>> >>>>> >>>>>> On Tue, Aug 21, 2018, 13:46 Romain Manni-Bucau <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> We can move all the code to extensions but id be for it only using >>>>>>> cdi2 as a base to avoid useless code. >>>>>>> >>>>>> >>>> That would be my preference as well. >>>> >>>> >>>>> >>>>>>> Annotated mode doesnt support producers sadly. >>>>>>> >>>>>>> Now my question is why osgi cdi doesnt support cdi 1.0 spec? We dont >>>>>>> use more in config impl I think. >>>>>>> >>>>>> >>>> The OSGi CDI spec is based on CDI 2.0. We didn't want to build >>>> something new that started with legacy. >>>> >>>> Cheers, >>>> - Ray >>>> >>>> >>>>> >>>>>>> Le mar. 21 août 2018 19:26, Raymond Auge <[email protected]> >>>>>>> a écrit : >>>>>>> >>>>>>>> I notice that there's a beans.xml file in the config impl. I'm also >>>>>>>> seeing that some beans are explicitly added via the SPI in >>>>>>>> ConfigExtension. >>>>>>>> >>>>>>>> Are there any beans which would be found via `annotated` beans >>>>>>>> discovery which are _not_ explicitly added in the extension? I also see >>>>>>>> that there are plenty of Vitoed classes. >>>>>>>> >>>>>>>> I'm wondering if we could unify things to not use beans.xml at all, >>>>>>>> and only use the extension SPI. This would ensure that things always >>>>>>>> work >>>>>>>> with the new OSGi CDI spec. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> -- >>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>> (@rotty3000) >>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>>>>> (@Liferay) >>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>>>>>> (@OSGiAlliance) >>>>>>>> >>>>>>> >>>> >>>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>> (@Liferay) >>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>> (@OSGiAlliance) >>>> >>> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
