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