How to run Jakarta EE 9 on WildFly

Welcome to Jakarta EE 9! We can finally have a taste of Jakarta EE 9 by downloading the Alpha version of WildFly 22. Let’s check it out

As many of you know, Jakarta EE 9 is a tooling release that aims at updating specifications to the new Jakarta EE 9 namespace (from javax.* to jakarta.*), and removing specifications that are no longer relevant. Although it does not include exciting new features Jakarta EE 9 is a key step on the road to further innovation using cloud native technologies for Java. As we will see, the shape of application servers won’t be again the same after Jakarta EE 9.

So let’s start by downloading WildFly 22, which includes a preview of Jakarta EE 9: https://wildfly.org/downloads

Next, unzip it as usual. We will now have a quick look at the application server.

A closer look at a Jakarta EE 9 application server

First of all, let’s check any enterprise api to see the new packaging:

$ jar tvf modules/system/layers/base/jakarta/servlet/jsp/api/main/jakarta.servlet.jsp-api-3.0.0-RC2.jar

  1169 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/BodyContent.class
   500 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/JspFragment.class
   358 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/PageData.class
   257 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/TryCatchFinally.class
   832 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/FunctionInfo.class
  2108 Thu Nov 12 21:02:12 CET 2020 jakarta/servlet/jsp/tagext/TagData.class
  . . . . 

So, as expected, now packages have been renamed from “javax” to “jakarta“. Does that mean we have to update all our applications, in order to change packages from “javax” to “jakarta” ? Actually not. The Rules of the game are defined by the Galleon tool which now includes the ‘wildfly-preview‘ feature pack to handle the transition to Jakarta EE 9.

In a nutshell, when suitable Jakarta EE 9 API jars or ‘native’ EE 9 implementation libraries are found, those will be used instead of the EE 8 spec jars used in standard WildFly. On the other hand, if you deploy a Jakarta EE 8 application on the top of WildFly 22, the features in galleon-preview will detect the old EE 8 API and will trigger a bytecode transformation to change references from javax.* to jakarta.*.

If you are interested to know more about the transformation project, check the Eclipse Transformer project (https://projects.eclipse.org/projects/technology.transformer) which contains part of the technology used in WildFly 22 to trasform your references.

Let’s have a test by starting WildFly 22 and deploying any EE 8 application on the top of it:

 ./standalone.sh

Now let’s deploy the WildFly 20 kitchensink quickstart on the top if it:

[wildfly@fedora kitchensink]$ mvn clean install wildfly:deploy

As you can see, the kitchensink deployed on WildFly 20:

10:01:05,449 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/kitchensink' for server 'default-server'
10:01:05,518 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "kitchensink.war" (runtime-name : "kitchensink.war")

jakarta ee 9

In the long run it, I reckon that development tools or IDE will perform out of the box a transformation of “javax” namespaces to “jakarta” so the transformation feature might not be required or it could become optional as well. We will see. Let’s see now some other differences contained in the new application server version.

No embedded messaging broker (by default)

The key change in WildFly 22 is the “messaging-activemq” which does not include (by default) an embedded Artemis MQ server:

<subsystem xmlns="urn:jboss:domain:messaging-activemq:11.0">
    <remote-connector name="artemis" socket-binding="messaging-activemq">
        <param name="use-nio" value="true"/>
        <param name="use-nio-global-worker-pool" value="true"/>
    </remote-connector>
    <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="artemis" transaction="xa" user="guest" password="guest"/>
</subsystem>

As you can see, the configuration in the “full” and “full-ha” profiles now include a Remote connector only to connect to an external Artemis MQ server. The logic behind this choice is that cloud applicatons are supposed to provide microservices so it’s discouraged to start an application server which provides both business logic and an embedded broker. So, in OpenShift terms, the best practice is to spin or or more Pods for the application server and one or more Pods for the Artemis MQ broker.

The features of the embedded broker are still there though. If you check the folder JBOSS_HOME/docs/examples/configs you will find the standalone-activemq-embedded.xml legacy configuration which includes the embedded broker.

Changes in WildFly security

The old legacy security subsystem has been removed from the configuration. Therefore elytron is the security layer used by WildFly from this release on. Picketbox libraries are still there though:

find . -name "picket*.jar"
 ./system/layers/base/org/picketbox/main/picketbox-5.0.3.Final-redhat-00007.jar
 ./system/layers/base/org/picketbox/main/picketbox-infinispan-5.0.3.Final-redhat-00007.jar
 ./system/layers/base/org/picketbox/main/picketbox-commons-1.0.0.final.jar

However they are planned to be removed completely when JDK 14 is out. As you can check from JDK 14 release notes (https://www.oracle.com/java/technologies/javase/14-relnote-issues.html), the PicketBox API is now obsolete for this JDK release.

For the same reason, the old vault tool is obsolete as well and it has been removed from the ‘bin’ folder of the application server. You are recommended to migrate from the vault password mechanism to Elytron Credential Stores Using Elytron Credential Stores in WildFly

The fall of the legacy subsystems

A number of legacy subsystems have been deprecated such as ‘cmp’, ‘config-admin’, ‘jacorb’, ‘jaxr’. Also, WildFly support for JSR-77 has been removed so you will not find the “jsr-77” subsystem any more. In replacement, it’s recommended to use the management layer to get this data. The management model has a native protocol with a Java API, and also has an HTTP/JSON protocol that can be used from any language.

That’s all! The WildFly 22 process is still in an early stage so not all the core features (mainly the transforming feature) are available in all contexts. For example, deployment overlays are not transformed with the alpha releases. Unmanaged deployments that use EE 8 APIs will not work as well.

For more info, check the release notes and its news: https://www.wildfly.org/news/2020/11/12/Jakarta-EE-9-with-WildFly-Preview/