Disabling of Security Manager in latest SE 24
by Brian Stansberry
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.
[1] https://openjdk.org/jeps/486
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
7 hours, 58 minutes
Testing WildFly with Java SE 24
by James Perkins
Hello All,
This is somewhat of a follow up to the "Disabling of Security Manager in
latest SE 24". I wanted to start a new thread because what this touches on
is a bit different.
Just an FYI for those projects using GitHub Actions. If you use Temurin,
you can use 24-ea as the version to test against.
One thing to note is WildFly will not currently boot with the latest
version of Java 24 due to MODULES-453
<https://issues.redhat.com/browse/MODULES-453> [1].
Also, the standard WildFly configuration will not boot, see WFCORE-7059
<https://issues.redhat.com/browse/WFCORE-7059> [2], but you can simply
workaround that by removing the jacc default policy, in most cases. The
simple CLI command is:
/subsystem=elytron/policy=jacc:remove
I've not done full testing with this solution, but it seems to work for the
tests I've done.
If you're using WildFly Arquillian there is one additional issue
<https://github.com/wildfly/wildfly-launcher/issues/6> [3]. I plan to do
another release of the wildfly-launcher API, new home, new GAV, and a new
WildFly Arquillian release by the end of this week.
[1]: https://issues.redhat.com/browse/MODULES-453
[2]: https://issues.redhat.com/browse/WFCORE-7059
[3]: https://github.com/wildfly/wildfly-launcher/issues/6
James R. Perkins
Principal Software Engineer
Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>
12 hours, 40 minutes
Configure vert.x in WildFly
by Kabir Khan
Hi,
At the moment the SmallRye/MP Reactive Messaging integration just uses a
default created vert.x.
I think otel uses vert.x too, probably in much the same way? Then there
might be other subsystems in various feature packs.
It seems there is some desire to be able to configure the vert.x instance
https://github.com/smallrye/smallrye-reactive-messaging/discussions/2725.
Being able to configure vert.x is TBH something I've totally ignored.
I guess this would mean a Vert.X subsystem, which can optionally create a
vert.x instance with the configured parameters. Does it make sense to
create more than one instance in case subsystems have slightly different
needs?
Then the reactive messaging subsystem can use that, if present (or perhaps
this should be a configuration parameter in the reactive messaging
subsystem). If not (or not configured to do so), it will use the default
like it does today.
Thanks,
Kabir
1 day, 2 hours
New feature: Active Request Tracking in Undertow
by Flavia Rainone
Hi all!
I have updated the analysis document for active request tracking in
Undertow.
The desired stability level is Default, but if it is not possible for WF
35, then I would like to aim for Preview level.
https://github.com/wildfly/wildfly-proposals/pull/275
Regarding the feature team, we need volunteers. I am looking for someone to
volunteer as the SME and also someone to volunteer to provide the outside
perspective.
Best regards,
Flavia
5 days, 14 hours
WildFly 34.0.1 release deadlines
by Paul Ferraro
Hi everyone,
I am planning to tag the WildFly 34.0.1 release on Thursday, 21 November.
This will require tagging and releasing wildfly-core this coming Friday, 15
November.
TCK runs will commence on Tuesday, 19 November, with final merges taking
place the day prior (the 18th).
Please ensure any pull requests intended for inclusion in WildFly 34.0.1
are submitted to their respective repositories [1][2] before these dates.
If you have something you want to get in for this release that may impact
the above dates, please let me know as soon as possible.
Thanks,
Paul
[1] https://github.com/wildfly/wildfly/tree/34.x
[2] https://github.com/wildfly/wildfly-core/tree/26.x
1 week, 1 day
