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