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)
