Red Hat JBoss EAP XP 6.0 release notes

You can now enable OpenTelemetry tracing for the MicroProfile Reactive Messaging Kafka connector in JBoss EAP. This integration leverages SmallRye Reactive Messaging support for OpenTelemetry to enhance the observability of Kafka-connected microservices. OpenTelemetry tracing provides visibility into message flows and performance across Kafka messaging interactions, allowing you to improve monitoring and issue resolution.

For more information, see Understand OpenTelemetry integration.

You can now enable OpenTelemetry tracing for the MicroProfile Reactive Messaging AMQP connector in JBoss EAP. This integration leverages SmallRye Reactive Messaging support for OpenTelemetry to enhance observability for AMQP-connected microservices. OpenTelemetry tracing provides visibilty into message flow and performance across AMQP messaging interactions, allowing you to improve monitoring and issue resolution.

For more information, see Understand OpenTelemetry integration.

JBoss EAP XP provides full support for MicroProfile Long Running Action (LRA) without HA capabilities. This is a standalone MicroProfile specification providing an API for distributed transactions handling based on the saga pattern. This provides a way for transaction handling without requiring a lock on remote resources.

In this release there was an alignment with Jakarta RESTful Web Services 3.1 to be compatible with Jakarta EE 10.

Implementations must close a client once the CDI bean falls out of scope. (348).

Added a String overloaded RestClientBuilder.baseUri() method to the API. (334).

Added a new RestClientBuilder.header(String, Object) method to add headers. The headers will be merged with headers added via other means (283).

The support for MicroProfile Fault Tolerance has been upgraded to version 4.1 in JBoss EAP, implemented by SmallRye Fault Tolerance. This release includes bug fixes, updates to enhance MicroProfile Fault Tolerance support, and integration with Telemetry metrics for improved observability.

Previously in JBoss EAP XP 5.0.0, MicroProfile Telemetry supported only OpenTelemetry Tracing. JBoss EAP XP 6.0.0 supports MicroProfile Telemetry 2.0. This update adds support for OpenTelemetry Metrics and OpenTelemetry Logs. Support for OpenTelemetry Tracing has been upgraded as well.

For more information, see the MicroProfile Telemetry in JBoss EAP and MicroProfile Telemetry administration, and Observability in JBoss EAP sections in Using JBoss EAP XP 6.0.

Support for the MicroProfile OpenAPI specification was updated from 3.1 to version 4.0 as part of version 7.0 of the MicroProfile platform specification, including API-incompatible changes. For more information about the API-incompatible changes, see 8.1.1. Incompatible Changes in the MicroProfile OpenAPI Specification Release Notes. As a consequence, you might need to update your applications to use the latest MicroProfile OpenAPI specification.

The MicroProfile BOM with Maven coordinates org.jboss.bom:jboss-eap-xp-microprofile has been renamed to the Expansion BOM with Maven coordinates org.jboss.bom:jboss-eap-expansion.

You can deploy multiple MicroProfile .war applications on the same standalone JBoss EAP XP server. Each application runs independently with its own configuration, MicroProfile Telemetry signals, and MicroProfile Long Running Action participants, operating as a fully isolated deployment.

With bootable JAR Support for JBoss EAP 8.1, JAR Maven plug-in has been deprecated in JBoss EAP XP 6 and the plug-in might be removed in a future release. Use the JBoss EAP Maven plug-in for packaging applications as a bootable JAR instead. For more information about additional resources, see {ProvisioningBookName}.

Bootable JAR mode for building JBoss EAP applications on OpenShift is now deprecated and may be removed in a future release. The builder image to build a Bootable JAR image now uses OpenJDK 17 on UBI 9.

In OpenTelemetry, there is a separate OpenTelemetry instance for each application. These instances share the same configuration, which results in metrics from each application being exported together.

Each OpenTelemetry-enabled application reports and tracks JVM and system metrics, which can affect the performance of your system and increase inefficiency.

This behavior can cause unexpected results in multi-deployment environments where applications are expected to operate in isolation.

A future release is planned to change this behavior to ensure OpenTelemetry metrics collection between deployments and between deployments and the underlying server system.

In Micrometer observability, all applications deployed on the same server instance share a single MeterRegistry. An application can access meters from another application and system meters by using the MeterRegistry.getMeters() method. An application can also remove meters from other applications or system meters by using the MeterRegistry.remove(Meter), MeterRegistry.remove(Meter.Id), or MeterRegistry.clear() methods.

This behavior exists in the current Micrometer implementation and can cause unexpected results in multi-deployment environments where applications are supposed to operate in isolation. A future release is planned to change this behavior to ensure proper metric isolation between deployments and between each deployment and the underlying server system.

Currently, JBoss EAP XP 6.0 does not support multiple deployments that use Micrometer in the same server instance. Support for this configuration is planned to be reconsidered in a future release after the underlying issue is resolved.

There are several non final OpenTelemetry artifacts shipped with JBoss EAP XP 6.0 due to MicroProfile specification requirements:

JBoss EAP XP 6.0 provides limited support for multiple deployments that use the MicroProfile OpenAPI subsystem. Each deployment must either use a different virtual host or configure a distinct, non-standard OpenAPI endpoint path.

Support for using the standard OpenAPI endpoint on the same virtual host is planned to be delivered in a subsequent update release.

In JBoss EAP XP 6.0, when an application sets the mp.health.disable-default-procedures=true configuration property, the server disables the default procedures. However, the server does not reset this state when the application is undeployed. As a result, default procedures remain disabled even when no deployed application defines this property.

This behavior can cause unexpected health check responses in multiple deployment environments.

To enable default procedures, reload the server after undeploying the application that defined mp.health.disable-default-procedures=true.

Support for automatically resetting this configuration property after undeploying the application is planned to be delivered in a subsequent update release.