[wildfly-dev] Re: Changes coming to WildFly

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