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 <raymond.a...@liferay.com>:
> 
> 
> 
> On Tue, Aug 21, 2018 at 1:57 PM, Romain Manni-Bucau <rmannibu...@gmail.com> 
> 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 <johndam...@apache.org> 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 <rmannibu...@gmail.com> 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 <raymond.a...@liferay.com> 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)

Reply via email to