8:47 p.m.
Hi folks,
There's been quite a bit of progress recently on development of an EE 9
variant of WildFly so I'd like to provide an update.
For context, the goal is to produce in Sept/Oct a
tech-preview/beta/milestone release of a variant of WildFly that exposes EE
9 APIs, so the community can get a chance to try those out. Most of the
implementation libraries in that release will use EE 8 APIs internally
(javax.* packages instead of jakarta.*) so to make that work, when Galleon
provisions an EE9 server it will bytecode transform any artifacts that use
EE 8 APIs into ones that use EE 9 APIs.
For deployments the server management layer will, when it reads in managed
deployment content, transform EE 8 APIs to EE 9. This allows existing apps
to work, which is particularly important for our testsuite, which is full
of EE 8 apps.
Thanks to a lot of hard work from Richard Opalka, Scott Marlow and
Jean-Francois Denise and the folks on the Eclipse Transformer project I
have a branch[2] that does this. It is based on the current WildFly master,
but overrides most of the EE spec artifacts to use the ones that were
included in the June EE 9 milestone release of Glassfish. It also overrides
a few of the spec impls with native EE 9 artifacts that were used in that
release.
That branch adds a new "ee-9" maven with a few child modules, the most
important of which are 'feature-pack' and 'dist'. The
'feature-pack'
module produces a Galleon feature pack which is analogous to the wildfly-ee
feature pack, but provides EE 9 APIs. The 'dist' module then builds a dist
using that feature pack.
At this point there is no EE 9 equivalent to the top level 'wildfly'
feature pack, which adds in the Eclipse Microprofile JWT, Fault Tolerance
and Open API specs. Dealing with those is a todo.
If you do a normal 'mvn install' of this branch, the ee-9 modules will
build.
To run part of the testsuite against the EE 9 dist, do this:
mvn install -Dts.ee9 -Dts.basic
That runs testsuite/integration's 'smoke', 'web', 'ws' and
'basic' modules.
Don't include -Dts.basic if you don't want the basic module to run.
Not all tests run; some for known reasons, some for unknown ones. But a
whole lot do.
Over the course of the next few days I'll be working to get more testsuite
modules to run with the ts.ee9 profile. Once that is done I'd like us to
give some thought to producing an alpha release of WildFly so folks can
more easily try this out.
There are some important difference between this feature pack and the
regular wildfly-ee one:
1) It does not depend on the wildfly-servlet feature pack. That feature
pack IMO is a bit of a evolutionary appendix that serves little purpose in
a Galleon driven architecture; it just adds complexity. So for this EE 9
feature pack I'm directly incorporating the content that would have been in
wildfly-servlet, instead of having a dependency on an EE 9 variant of
wildfly-servlet.
It is tempting to do the same with the wildfly-core feature pack. Something
to discuss.
See [ <https://github.com/wildfly/wildfly/pull/13394>4] for more on this.
2) It does not include the legacy picketbox-based security subsystem. We
want to move to a purely Elytron-based security architecture so legacy
picketbox security is being left behind.
This brings some interesting challenges, as it surfaces a few places where
there's a default expectation for legacy security, with the user having to
do work they shouldn't have to to make that go away. Darran Lofthouse has
been looking at this.
It also brings some effort on the testing side, just because quite a few
tests expect legacy security. We've dealt with that before with running
tests with pure elytron configs.
Picketbox is still present, which means the security vault works, but I
expect at some point that will be removed. Right now it was easier to leave
it in place; otherwise it would have been removed as Picketbox is a barrier
to using JDK 14 or later.
3) The default messaging subsystem config does not include an embedded JMS
broker. Instead it is configured to point to a remote Artemis broker. Using
an external broker is a more cloud-native way to deploy an app, which is
why this variant is moving that way. The docs/examples/configs dir includes
a standalone-activemq-embedded.xml config that provides the embedded broker.
This definitely brings a big testing challenge as almost all of our tests
involving messaging, including EJB MDB tests, assume the embedded broker is
present. A quick workaround would be to run those against a server using
the example standalone-activemq-embedded.xml config, but we also need to
work out proper testing for the standard config that uses a remote broker.
4) The feature pack doesn't include various misc stuff that we either
intended to prune from WF in general at some point (JSR77, picketlink
extension, legacy subsystems that only provide domain-mode Domain
Controller support for AS 7 hosts) or where it wasn't clear what we'd do so
I left things behind just to reduce the initial scope (agroal, versions of
Hibernate other than 5.3).
5) As noted above, this is equivalent to a wildfly-ee feature pack so it
doesn't include MP FT, JWT or OpenAPI.
6) A 'thin server' (where JBoss Modules finds artifacts in maven, rather
than in the local modules dir) does not work really well, as the
transformed artifacts are not in the usual local or remote maven repos.
There are things you can do in this area, but that's too much of an
advanced case to get into here.
Besides what I noted above there are some known issues, just in case you
experiment and hit them:
a) Transforming unmanaged EE 8 apps to EE 9 is not supported. This likely
won't change for quite a while if ever. (Note: zipped apps deployed by the
deployment scanner *are* managed apps. This limitation primary relates to
exploded deployments.)
b) The transformation of the jastow library needs improvement so the
classes it generates from JSPs properly use the jakarta packages.
c) The JSF impl doesn't properly provide a jsf.js file.
I'm aiming to frequently merge master into this branch, so it keeps up to
date with changes in master. It might make sense to create an ee-9 branch
in the wildfly/wildfly github repo just to make it easier to coordinate
updates, run CI etc. But for now I'm happy to receive PRs against this
branch in my repo.
I encourage people to give this a spin.
If you're looking for things to do on this topic, please reach out to
myself or Scott Marlow or Richard Opalka. There's plenty to do but this
post is already way too long!
Best regards,
Brian
[1] https://wildfly.org/news/2020/06/23/WildFly-and-Jakarta-EE-9/
[2] https://github.com/wildfly/wildfly/pull/13453 and
https://github.com/bstansberry/wildfly/tree/ee-9
[3]
https://github.com/wildfly/wildfly/tree/master/ee-feature-pack/galleon-fe...
[4] https://github.com/wildfly/wildfly/pull/13394