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? 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) >
