On Tue, Aug 21, 2018 at 4:04 PM, Raymond Auge <[email protected]> wrote:
> > > 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. > i.e. YES I always test at build time. :) > > - 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) > -- *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)
