WildFly Technology Interest Survey
by Brian Stansberry
If you have 10-15 minutes for an anonymous survey, we'd love to get your
responses to the WildFly Technology Interest Survey!
https://forms.gle/heh23E6kvSmAJnR97
There have been lots of changes over the last few years in the standards
like Jakarta EE and MicroProfile that WildFly implements, and those standard
s will continue to evolve. And of course there are lots of technologies
that WildFly provides or could provide. We'd love to know more about what
technologies you're using or would like to use with WildFly. So, please
take this chance to let us know what's important to you!
Thanks and best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 week, 1 day
New feature: Support Jakarta Data in standard WildFly
by Brian Stansberry
Hello,
I'm looking for folks who'd like to participate in the feature team for
https://github.com/wildfly/wildfly-proposals/issues/608 for WildFly 35 (so
over the next week.)
We introduced Jakarta Data in WildFly Preview 34, at 'preview' stability,
and the integration should work fine in standard WF as well. It has no
dependencies that we don't provide in standard WF and is based on std WF's
Hibernate ORM 6.6. So this is largely a matter of moving a few bits so they
are part of ee-feature-pack/galleon-shared instead of preview/galleon-local.
The analysis is at https://github.com/wildfly/wildfly-proposals/pull/666.
Let me know if you're interested!
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 weeks, 3 days
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
3 weeks, 1 day
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/>
3 weeks, 1 day
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
3 weeks, 2 days
