Welcome to Jakarta EE 9! In this tutorial we will learn how to get started with Jakarta EE 9 by downloading WildFly EE 9 Preview.
Overview of Jakarta EE 9
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.
In order to use Jakarta EE 9, you can download the EE 9 Preview Distribution of WildFly Server (from WildFly 22 on) from: 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, if you deploy valid Jakarta EE 9 API jars or ‘native’ EE 9 implementation libraries, the application server will detect and use them. 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 which WildFly uses 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")
Disable Automatic transformation:
WildFly Preview’s automatic transformation of deployments can be disabled by adding the following system property to WildFly launch:
-Dorg.wildfly.unsupported.skip.jakarta.transformer=true
In the long run it, it’s likely that development tools or IDE will perform out of the box a transformation of “javax” namespaces to “jakarta” so you might not need the transformation feature at all. We will see. Next, let’s check now some other highlights of the WildFly EE 9 preview 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.
Latest News
As announced on the official WildFly Blog (https://www.wildfly.org/news/2022/01/21/WildFly-2022/), the WildFly 26.1 release will be the last that support EE 8. Therefore, be prepared to migrate to Jakarta EE 9 soon! Also, WildFly 26.1 releases will be the last that support SE 8. WildFly 27 will require SE 11 or later.
Found the article helpful? if so please follow us on Socials
