Yes, I wanted to get this message out promptly so I didn't get into the subtleties. Thanks, Matej for asking and Darran for responding.

If a component has a stream that is bound to EE 11 and we don't use it outside of that context, it's ok to drop SM calls. EE 11 doesn't support SM and any WF runtime that runs EE 11 will fail boot if the SM is enabled. But WF is likely going to support EE 10  as an EE 11 alternative for quite a while.

Think a bit about this though; don't just assume your component is only used in the EE 11 context. That's not an issue for Weld but keep it in mind when it comes to lower level things. And there are a lot of components that are shared between EE 10 and 11 because the relevant spec didn't do an update for 11.

On Tue, Nov 19, 2024 at 10:50 AM Darran Lofthouse <darran.lofthouse@jboss.com> wrote:
I think in this regard we will be using different versions of Weld for Jakarta EE 10 support and Jakarta EE 11 support so it will be fine if the Jakarta EE 11 branch has dropped security manager support.

Where one version of a component may be used for Jakarta EE 10 and 11 then security manager support will need to be retained.


On Tue, Nov 19, 2024 at 4:27 PM Matej Novotny <manovotn@redhat.com> wrote:
Hello Brian

Speaking for Weld codebase, I have already removed SM references for the upcoming Weld 6 (EE 11, CDI 4.1) some time ago.

I did that based on the fact that EE 11 states that it removes all use of SM as one of its key changes (https://jakarta.ee/specifications/platform/11/).
Plus, I am also aware of the WFLY issue that aimed to fail boot in EE 11 if SM was detected - https://issues.redhat.com/browse/WFLY-19287

However, based on your email, it seems that this is a problem for WFLY but I am failing to see why.
If EE 11 doesn't aim to support SM, why do we need to keep it in future WFLY versions?

Regards
Matej

On Tue, Nov 19, 2024 at 4:27 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
tl;dr; Do not remove security manager calls from WildFly or its components! Not unless you want and are able to maintain a branch supporting them for many years.


I don't know all the details, but from a few discussions I've seen in the last hour it seems that the promised removal of runtime support for the Security Manager[1] has landed in an SE 24 update.

This change means in an SE 24 environment you can no longer enable the SM and it will fail if you try. So this will certainly affect our code that's meant to run on SE 24 and later; we'll need to adapt to not try and turn it on.

What this *should not* mean is calls to SM-related APIs in SE will fail. They should still work; they just don't do any enforcement. This isn't some odd situation since for decades now the vast majority of calls to SM APIs don't result in enforcement -- because the user doesn't enable the SM.

WildFly is going to support Java SE versions where the SM works for many many more years. It's only in the upcoming WF 35 that we're dropping support for SE 11. So who knows how much longer we'll need to support SE 21.

If you break SM support in a component, that stream will no longer be usable in typical WF!

We'll need to do things to prepare for the day when SM APIs are removed from SE and we shouldn't ignore that task. But please don't break things.

Kudos to those of you like Richard Opalka and James Perkins who are keeping an eye on things and noticed this promptly.

--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/THIQ2ZQ5SDMCWIFH2J4CDENR7H2IXBCH/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/OGIRA4XJAH5AFEBN2MHB22KVFCU5M4FK/


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His