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&gt; 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

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&gt; 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&gt; 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&gt; 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

OK let me try to be more clear. Weld will support CDI Lite, but it will achieve that support by implementing CDI Full. It won't be possible to strip down Weld only to Lite. At least that's my current understanding. LT On Wed, Sep 29, 2021 at 5:37 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > 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&gt; 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&gt; 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&gt; 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&gt; 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 >