10:36 a.m.
Thanks, Ladislav. So it sounds like WF will have flexibility to deal with
CDI Lite in the way that fits best.
I'm not sure if there's a critical use case for trying to limit a WF
installation that uses CDI to just CDI Lite. From what you describe I
suspect there wouldn't be a big footprint benefit. (For there to be one the
Portable Extensions logic would need to be in a separate artifact/module
that wouldn't be provisioned. Perhaps some runtime memory differences
and/or a reduced security attack surface. But anyway if there is a benefit
worth the effort we could look into how to provide that kind of limited
integration; otherwise we can just stick to full CDI.
On Wed, Sep 29, 2021 at 1:30 AM Ladislav Thon <lthon(a)redhat.com> wrote:
Hi,
when it comes to CDI Lite, the intent is that Lite is a strict subset of
Full. Lite includes the new extension API (provisionally called Build
Compatible Extensions). Full includes both Portable Extensions and Build
Compatible Extensions (because it includes complete Lite). We didn't want
to mess with Weld internals to support 2 extension APIs, so the new
extension API is implemented as a standalone Portable Extension. That is
the "adaptor" Scott mentions.
The way I see it, Weld would always include this adaptor, because that's
the only way for it to be compliant. So that's not something that would
have to be integrated on the WildFly level (except perhaps making sure that
the Portable Extension is "discovered" -- not sure if that's necessary).
Again, given that Lite is a strict subset of Full, Weld implementing Full
should very much be compliant with Lite. If the Core Profile demands CDI
Lite, it is my opinion that an implementation supporting CDI Full should be
just fine.
LT
On Tue, Sep 28, 2021 at 8:59 PM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Good question.
>
> I'd like to be able to support core profile in some way, but I'm not sure
> if something like a new standard config "standalone-core.xml" makes sense,
> vs just having appropriate Galleon layers to make it easy to compose a
> server with the profile.
>
> Do you all foresee the proposed adaptor for portable extensions as being
> something that could be integrated in WF? If not would supporting full CDI
> prevent certification as a Core Profile compliant?
>
> On Tue, Sep 28, 2021 at 11:09 AM Scott Stark <sstark(a)redhat.com> wrote:
>
>> Brian, do you envision that Wildfly would support a Core profile
>> configuration for EE10? Weld will support the CDI Lite specification, but
>> it will run with an adaptor for portable extensions that
>> downgrades/restricts the allowed behavior to Lite extension (Ladislav,
>> Matej, correct me if I'm wrong here) that may not be ideal.
>>
>> On Mon, Sep 27, 2021 at 2:11 PM Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> There are a lot of changes coming in WildFly as we move on from legacy
>>> security, pivot toward Jakarta EE 10 and the jakarta.* package namespace,
>>> and keep up with progress in Java SE. I've blogged about how I see
things
>>> changing in WildFly over the next few releases. See
>>>
>>> https://www.wildfly.org/news/2021/09/27/WildFly-Changes/
>>>
>>> I'd love to hear your thoughts and questions about all of this!
>>>
>>> Best regards,
>>> Brian Stansberry
>>> Project lead -- WildFly
>>> He/Him/His
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> He/Him/His
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His