WildFly Calendary Proposal
by Jason Lee
I have a PR open that is a first step in creating a calendar of
WildFly-related events: https://github.com/wildfly/wildfly.org/pull/439
Brian does a great job of emailing the WF dev schedule to this list, but,
for me, it tends to get buried and lost. What I'd love to be able to do is
subscribe to a .ics and have events show up on my calendar. This is a step
toward that. What would be nice is to take that one step further and make
it available in a human-friendly form on wildfly.org as well.
All that said, I would love feedback on the idea itself, the contents of
the calendar, etc. to see if this would be useful to more than just myself.
Additionally, I know we have various community efforts going on at the
moment, so if this overlaps with any of that, I'm happy to roll this into
those efforts.
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
10 months, 2 weeks
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 year
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
1 year
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
1 year
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/>
1 year, 1 month
