Jakarta EE 10 is on its way with WildFly 27

WildFly 27 (Alpha) is now available. On the the top features of this releases is the preview support for some of Jakarta EE 10 features plus several product enhancement. This article launches you on a tour of this new release by focusing on fundamentals.

Jakarta EE 10 status in WildFly

WildFly 27 Alpha is the first milestone towards Jakarta EE 10 Core Profile. At the time of writing, Jakarta EE 10 is not yet finalized. However, some of its API are already accessible. If you want to check the status of the single APIs which are part of Jakarta EE 10 core profile, the following JIRA is the main place holder: https://issues.redhat.com/browse/WFLY-15679

This picture summarizes the status of Jakarta EE 10 implementation in WildFly 27 Alpha:

The following API ( with a plain fill colour in the above picture) are currently available (at the time of writing) in WildFly 27 preview :

• JSON-P 2.1
• Annotations 2.1
• CDI 4.0
• Interceptors 2.1
• Mail 2.1
• Activation 2.1

Therefore, let’s try deploying a sample Web application which uses one of the above API.

Building a sample application

Firstly, we need to download WildFly 27 Preview from https://www.wildfly.org/downloads/

Next, make sure you have a JDK 11 or above as WildFly 27 mandates the usage of Java 11 as minimal version.

Within this project, we will check the JSON-B 3.0 API . As a matter of fact, this release adds the capability to use Polymorphic type handling for deserialization and serialization. Polymorphic handling is carried out by annotation JsonbTypeInfo and @JsonbSubtype.

JsonbTypeInfo defines the following:

• A key name of the property to store type information in it
• A set of aliases using @JsonbSubtype annotations

@JsonbSubtype ensures proper and safe mapping between class alias and type. Type information is obtained from @JsonbSubtype annotation as a type alias mapped to the type. If no matching class is found for obtained alias during deserialization, an exception will be thrown.

To begin, let’s add a top level Class Employee which maps two subtypes (Manager and Consultant) with their respective aliases:

@JsonbTypeInfo(key = "@employee", value = 
 {@JsonbSubtype(alias = "manager", type = Manager.class),@JsonbSubtype(alias = "consultant", type = Consultant.class)})
public class Employee {

	public Employee() {
		super();
	}
}

Then, we will add the two subclasses, which are barely extending the Employee Class and carrying an additional property:

public class Manager extends Employee {
 
	public boolean isManager = true;

	public Manager() {
		super();
	}
 
}

public class Consultant extends Employee {
	public boolean isConsultant = true;

	public Consultant() {
		super();
		 
	}

}

After that, we will serialize the Employee to JSON with a couple of Jakarta REST Endpoints:

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/manager")
    public Response createManager() {
    
        
        Response response;
        Employee e = new Manager();

        Jsonb jsonb = JsonbBuilder.create();
        String jsonString = jsonb.toJson(e);
        response = Response.ok(jsonString).build();

        return response;
    }

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    @Path("/consultant")
    public Response createConsultant() {

    	Response response;
        Employee e = new Consultant();

        Jsonb jsonb = JsonbBuilder.create();
        String jsonString = jsonb.toJson(e);
        response = Response.ok(jsonString).build();

        return response;
    }

Building and Testing

Finally, to build the project we will use the jakarta.platform:jakarta.jakartaee-api:9.0.0 until Jakarta EE 10 is fully released. However, we can override the single projects which already have a Jakarta EE 10 implementation. In our case, the JSON-B 3.0 :

<dependencies>
	<dependency>
		<groupId>jakarta.platform</groupId>
		<artifactId>jakarta.jakartaee-api</artifactId>
		<version>9.0.0</version>
		<scope>provided</scope>
	</dependency>
	<!-- https://mvnrepository.com/artifact/jakarta.json.bind/jakarta.json.bind-api -->
	<dependency>
		<groupId>jakarta.json.bind</groupId>
		<artifactId>jakarta.json.bind-api</artifactId>
		<version>3.0.0</version>
	</dependency>
</dependencies>

Finally, we can test the application through the REST Endpoints:

$ curl http://localhost:8080/helloworld/rest/jsonb/consultant
{"@employee":"consultant","isConsultant":true}

$ curl http://localhost:8080/helloworld/rest/jsonb/manager
{"@employee":"manager","isManager":true}

As you can see, the JSON also includes the alias for the Employee object which we have serialized to JSON. As a matter of fact, you can now ensure backwards mapping to the proper type without needing to know it beforehand.

Source code for this example: https://github.com/fmarchioni/mastertheboss/tree/master/jakartaee/jakartaee-10

WildFly 27 new features

Jakarta EE 10 is definitely the top pick for this server release. However it also includes several new Features, Components upgrades and enhancements. At the time of writing, here is the list of the top new features you can expect for the next major version of the application server (some of them are already available in the Alpha1/Alpha2 version of it).

Distributable ejb subsystem

The purpose of the distributable-ejb subsystem is to encapsulate the configuration of ejb3 subsystem in a cluster.
As a matter of fact, this is quite similar to the distributable-web subsystem which encapsulates a set of profiles to cluster Web application, decoupling the Undertow subsystem from the actual clustering implementation. (Se this article for more details: WildFly Configuring HTTP Session in a cluster )

Here is an overview of the distributable-ejb subsystem:

<subsystem xmlns="urn:jboss:domain:distributable-ejb:1.0" default-bean-management="default">
    <infinispan-bean-management name="default" cache-container="ejb" cache="dist" max-active-beans="10000"/>
    <infinispan-client-mappings-registry cache-container="ejb" cache="client-mappings"/>
</subsystem>

By default, the following elements are in the subsystem:

The infinispan-bean-management provider element represents a bean manager implementation based on an Infinispan cache. The
attributes for the infinispan-bean-manager element are the following ones:

• cache-container refers to a cache container defined in the Infinispan subsystem used to support the session state cache
• cache specifies the session state cache and its configured properties
• max-active-beans refers the maximum number of non-passivated session state entries allowed in the cache

Then, the infinispan-client-mappings-registry is a provider based on an Infinispan cache and suitable for a clustered server.

• cache-container specifies a cache container defined in the Infinispan subsystem used to support the client mappings registry
• cache specifies the cache and its configured properties used to support the client mappings registry

Hibernate 6 support

The long-waited new major release of Hibernate is now available in the list of JPA providers. Here is the next list of JPA Providers you will be able to use for WildFly 27:

• eclipselink
• hibernate5
• hibernate5_3
• hibernate6
• openjpa

Hibernate 6 features several enhancements. As a matter of fact, the most remarkable ones are in terms of performance (JDBC Performance, HQL Translation Performance, Criteria Translation Performance)

Integrate NATIVE_S3_PING discovery protocol

NATIVE_S3_PING is a discovery protocol that you can use for JGroups servers running in AWS EC2. While there are other protocols that can you can plug-in in such an environment (such as TCPPING, JDBC_PING), the NATIVE_S3_PING is an ideal fit. NATIVE_S3_PING performs node discovery by writing and reading from an S3 bucket. You can configure this protocol automatically from system properties.

Finally, the following example shows how you can apply the NATIVE_S3_PING protocol on a tcp JGroups Stack:

batch
/subsystem=jgroups/stack=tcp/protocol=MPING:remove()
/subsystem=jgroups/stack=tcp/protocol=org.jgroups.aws.s3.NATIVE_S3_PING:add(add-index=0, module="org.jgroups.aws.s3", properties={region_name="us-east-1a", bucket_name="jgroups-s3"})
run-batch

Log warning when MP Health reports DOWN

The Interface HealthLogging, which is available for Microprofile Health checks, now includes the capability to track in the server logs when the health status is DOWN. Here is the new HealthLogging inteface, including the healthDownStatus method:

interface HealthLogging extends BasicLogger {
    HealthLogging log = Logger.getMessageLogger(HealthLogging.class, HealthLogging.class.getPackage().getName());

    @LogMessage(level = Logger.Level.ERROR)
    @Message(id = 1000, value = "Error processing Health Checks")
    void healthCheckError(@Cause Throwable throwable);

    @LogMessage(level = Logger.Level.INFO)
    @Message(id = 1001, value = "Reporting health down status: %s")
    void healthDownStatus(String cause);
}

Conclusion

In conclusion, we have covered the status of WildFly 27 progress. Currently the application server is progressing towards the next Alpha 2 version and some new features will be added on the road. Most importantly, Jakarta EE 10 is almost here.