Makes sense. If not final then, if possible, let's try to 100% ensure our impls work as that (based on standalone and ee models). Can be better than changing impls for OSGi on the long run :).
Le ven. 24 août 2018 21:19, Raymond Auge <[email protected]> a écrit : > > > On Fri, Aug 24, 2018 at 3:15 PM, Raymond Auge <[email protected]> > wrote: > >> Romain, to clarify your question about testing, which I'm only now >> finally grasped; I wouldn't want to add such tests just yet because the >> OSGi CDI integration spec is not final, nor is the RI. So I wouldn't want >> to add SNAPSHOT things into the already usable geronimo-config-impl. >> >> However, once it's final it will be very simple to add tests just like >> you have for the other runtimes. >> >> Does that make sense? >> >> - Ray >> >> >> On Fri, Aug 24, 2018 at 5:22 AM, Mark Struberg <[email protected]> wrote: >> >>> In any case we must guarantee that the beans we need do not get picked >>> up twice (via Extension manually + scanning). >>> >>> > The OSGi CDI spec is based on CDI 2.0. We didn't want to build >>> something new that started with legacy. >>> >>> Except that EE8 is not yet widely used. >>> But having geronimo-config based on EE7 doesn't restrict osgi-cdi from >>> using it. It's all perfectly backward compatible. >>> >> > Very true! > - Ray > > >> >>> LieGrue, >>> strub >>> >>> >>> > Am 21.08.2018 um 20:16 schrieb Raymond Auge <[email protected] >>> >: >>> > >>> > >>> > >>> > 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. >>> > >>> > >>> > 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é (@rotty3000) >>> > Senior Software Architect Liferay, Inc. (@Liferay) >>> > Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) >>> > >>> > >>> > >>> > -- >>> > Raymond Augé (@rotty3000) >>> > Senior Software Architect Liferay, Inc. (@Liferay) >>> > Board Member & EEG Co-Chair, OSGi Alliance (@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) >
