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.


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

Reply via email to