A few days ago, Red Hat released the major version 7 of the open source Java EE application server, Red Hat JBoss Enterprise Application Platform (JBoss EAP).

Red Hat JBoss Enterprise Application Platform (JBoss EAP) is the supported and quality assured version of the WildFly application server from the JBoss community.

The JBoss EAP 7 is based on the version 10 of the WildFly application server. In 2013 Red Hat renamed the JBoss AS community project to WildFly to avoid confusion with the JBoss brand which referred to several different things at once, the application server, the JBoss Community, and a range of other JBoss Products.

The main improvements and highlights of the JBoss EAP 7 release

This article focuses on the following main improvements and highlights of the new major release of the JBoss EAP 7:

• implementation of the new specifications of the Java Enterprise Edition 7
• enhanced modularity
• management improvements
• component updates
• compatibility and interoperability

Implementation of the Java Enterprise Edition 7 specification

Java EE 7 is the current specification of the Java Enterprise Edition. JBoss EAP 7 implements the full Java EE 7 specification and is a certified Java EE 7 application server for the Java EE Web and Full profile.

The main goals of Java EE in Version 7:

• Increased developer productivity by adding more annotated POJOs and reducing boilerplate code
• Integration of HTML 5 with WebSockets and JSON support, better REST integration, Non-blocking I/O support with the Servlet API 3.1
• New specification for batch processing and concurrency and an update of the JMS specification with a simplified API

The following graphic shows an overview of the specifications included in the Java EE 7.

Most specifications are minor updates with a few improvements. The orange marked ones in the illustration are new specifications.

New specification:

• Java API for WebSocket 1.0 (JSR 356)
• Batch Applications for the Java Platform (JSR 352)
• JSON Processing (JSR 353)
• Concurrency Utilities for Java EE (JSR 236)

The Java EE 7 umbrella specification includes a major release of the Java Messaging Service (JMS) specification (JSR 368) and Java API for RESTful Services (JAX-RS) (JSR 339). JMS 2.0 provides a new simplified API to reduce boilerplate code for sending and receiving messages. The JAX-RS specification in version 2.0 supports a fluent Java based API to access REST APIs or other Web resources.

Enhanced Modularity

The base architecture has been split up into a more modular structure with a separated core. The WildFly community offers two distributions:

• Java EE Full and Web distribution
• Servlet-only distribution

At the moment the JBoss EAP 7 distribution is only available as Java EE Full and Web distribution.

The core based on the modular class loading and service architecture with JBoss Modules and the Modular Service Container (MSC). This is the base runtime for JBoss EAP and WildFly. The core contains the basic infrastructure such as deployment architecture and unified management APIs.

The Servlet-only distribution is a lightweight web distribution with the new web server Undertow. This distribution is useful for web applications, which require only a servlet container and come with their own web frameworks.

The Java EE7 Full and Web distribution is a fully compliant Java EE application server distribution with all Java EE implementations and services such as messaging, transaction, security, clustering, etc.

Management Improvements

Since the release of JBoss EAP 6, the improvement and enhancement of the management interfaces are ongoing goals.

Offline CLI Support

One new feature is the ability to embed a JBoss EAP process inside the CLI process to configure the Application Server without a running Server instance and any bound ports. This feature is similar to admin-only mode.

./jboss-cli.sh
[disconnected /] embed-server --admin-only=true -c=standalone.xml
[standalone@embedded /]

Graceful Shutdown

For rolling updates without any downtime, the JBoss EAP 7 now supports a graceful shutdown of the server process. The JBoss EAP 7 sever instance can be suspended via the command line interface.

:suspend(timeout=z)

When suspended, no new requests are accepted. When the suspension process completes, the server can be stopped without aborting any active requests or transactions. The behavior of the application server depends on the subsystem and may vary. As example the undertow subsystem reject new requests with a HTTP Error 503 – Service unavailable. Clustering could fail-over sessions and mod_cluster could notify load balancer.

The state of suspended server can be requested with the following CLI command.

:read-attribute(name=suspend-state)

There is the possibility to resume a suspended server or to shutdown the server process.

:resume

:shutdown(timeout=x)

Port Reduction

By utilizing HTTP upgrade, JBoss EAP 7 has moved nearly all of its protocols to be multiplexed over two HTTP ports:

• a management port (9990)
• an application port (8080)

The management port is bounded on the management interface and will be used for booth HTTP/JSON API and the native API.

The application port is bound on the public interface and can be used for EJB Invocation, remote JNDI and all HTTP based invocations.

However, other ports or all off the previously configured ports can still be enabled if desired.

Cloning Configuration Profiles in Domain Mode

The domain mode now supports the cloning of profiles with a single command via CLI

[domain@localhost:9990 /] /profile=default :clone(to-profile=default-copy)

HA Singleton Deployments

JBoss EAP 7 introduces a “singleton” subsystem for configuration of a set of policies for HA singletons in cluster environments.

<subsystem xmlns="urn:jboss:domain:singleton:1.0">
<singleton-policies default="default">
<singleton-policy name="default" cache-container="server">
<simple-election-policy/>
</singleton-policy>
</singleton-policies>
</subsystem>

A singleton policy defines:

• A unique name
• A cache container and cache with which to register singleton provider candidates
• An election policy – simple, random, and preferences
• A quorum (optional)

A singleton deployment can be activated via a singleton-deployment.xml descriptor in the META-INF directory.

<singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>

Component updates

Undertow – the New High Performance Web Server

The JBoss Web (aka Tomcat) was replaced by the new Undertow web server. Undertow supports the new HTTP 2 standard, non-blocking and blocking handlers, traditional and asynchronous servlets, and JSR-356 web socket handlers. Undertow is designed to be fully embeddable and supports easy to use fluent APIs.

Goodbye HornetQ – Welcome ActiveMQ Artemis

ActiveMQ Artemis is the new message broker in JBoss EAP 7. The HornetQ codebase was donated to the Apache ActiveMQ project, and the HornetQ community joined to build a next-generation messaging broker. This was materialized in the first major release of the ActiveMQ Artemis project. ActiveMQ Artemis includes many new features, and also retains protocol compatibility with the HornetQ broker. JBoss EAP 7 includes this new project as its JMS broker, and due to the protocol compatibility, it fully replaces the HornetQ project.

ActiveMQ Artemis is compatible with HornetQ clients and supports a number of other protocols such as AMQP, MQTT, Stomp, OpenWire and also JMS 2.

IIOP Implementation switched from JacORB to OpenJDK Orb

The IIOP implementation changed from JacORB to a downstream branch of OpenJDK ORB. This change should lead to better interoperability with the JVM ORB and the Java EE RI.

WildFly Elytron replaced PicketBox

WildFly Elytron is a new WildFly subproject which replace the combination of PicketBox and JAAS as the client and  server security mechanism.

Update to Hibernate 5 and Jipijapa

The Jipijapa project is an abstraction layer that allows the integration of different JPA persistence providers. JBoss EAP 7 comes with the following Jipijapa abstraction layer:

• Hibernate 5, 4.3 and 4.1
• OpenJPA
• EclipseLink

Other JPA persistence providers or your own JPA implementation can be integrated via the Jipijapa SPI.

Compatibility and Interoperability

The architecture is still based on the modular service and class loading concept. Also, the interfaces for configuration and management continue to be based on the De-Typed Management API. Therefore, the application server is mostly compatible and it can be expected with only little efforts to migrate JBoss EAP 6 environments to the new major release JBoss EAP 7.

With this release, Red Hat also focused on interoperability between the previous version JBoss EAP 6.

JBoss EAP 7 remote EJB invocations are interoperable between JBoss EAP 6 and JBoss EAP 7. The invocations are performed via the EJB Client API and JNDI lookups via the Remote Naming implementation.

The new messaging broker ActiveMQ Artemis is backwards compatible with JBoss EAP 6 and HornetQ. The message journals can be im- and exported with the command line interface.

A managed domain controlled by a JBoss EAP 7 domain controller can also manage JBoss EAP 6 domain hosts and servers.