Differences between MicroProfile 5.0 and 4.1
If you are updating your application from using MicroProfile 4.1 features to using MicroProfile 5.0 features, changes in API behavior might require you to update your application code.
MicroProfile 5.0 includes the Jakarta RESTful Web Services 3.0 feature (restfulWS-3.0). This version of the feature introduces changes in API behavior from the previous version (jaxrs-2.1) that might require you to update your application code. For more information, see Differences between Jakarta RESTful Web Services 3.0 and Java Restful Services (JAX-RS).
Differences between MicroProfile REST Client 3.0 and 2.0
With the release of the MicroProfile REST Client 3.0 feature (mpRestClient-3.0
), the underlying MicroProfile REST Client implementation for Open Liberty changes from Apache CXF to RESTEasy. This change results in certain API behavior changes that might require you to update your application code.
If you update your server from an earlier version of the MicroProfile REST Client feature to version 3.0, changes in API behavior might require you to update your application code. The following sections detail changes in behavior between the mpRestClient-2.0
and mpRestClient-3.0
features.
Injection for the @Context annotation is not provided in ClientHeadersFactory instances
In MicroProfile REST Client 3.0 and later, Open Liberty does not support the @Context
annotation as a portable injection mechanism in ClientHeadersFactory
instances. Code similar to the following example works with MicroProfile REST client 2.0, but fails in version 3.0.
public class CustomClientHeadersFactory implements ClientHeadersFactory {
@Context
private UriInfo uriInfo;
@Override
public MultivaluedMap<String, String> update(MultivaluedMap<String, String> incomingHeaders,
MultivaluedMap<String, String> clientOutgoingHeaders) {
MultivaluedMap<String, String> myHeaders = new MultivaluedHashMap<>();
URI uri = uriInfo.getAbsolutePath(); // this line throws a NullPointerException in mpRestClient-3.0
myHeaders.putSingle("INJECTED_URI_INFO", uri == null ? "null" : uri.toString());
return myHeaders;
}
}
Although no direct substitution exists for code such as this, one workaround is to register a ClientRequestFilter
instance and then obtain configuration details from the passed-in ClientRequestContext
object. You can then store those objects in a ThreadLocal
instance that is read in the CustomClientHeadersFactory
class.
MicroProfile Fault Tolerance @Timeout annotation is not supported for synchronous REST client methods
In MicroProfile REST client 2.0 and earlier, you could use @Timeout
annotation to set timeouts for synchronous REST client interface methods. This configuration is not valid in the MicroProfile Rest Client 3.0 implementation. Instead, to configure your synchronous REST client methods to time out at a certain time, you must use the RestClientBuilder#connectionTimeout
and RestClientBuilder#readTimeout
APIs or configure the timeouts with MicroProfile Config. For more information, see MicroProfile 3.0: Support for MicroProfile Config.
Only synchronous REST clients are affected by this change. The @Timeout
annotation still works the same for asynchronous REST client methods in MicroProfile REST client 3.0 as it did in previous versions.
Enable CDI interceptors by using the @Priority annotation
If you package CDI interceptors and bind them to a REST client interface, you must enable them by using the @Priority
annotation. In previous MicroProfile REST client versions, you could also enable them by using the beans.xml
file but this option is not available in version 3.0 and later.
The following example shows the @Priority
annotation on an interceptor class.
@Loggable
@Interceptor
@Priority(10)
In this example, 10
is a sample value that determines the order in which interceptors are invoked when more than one exists.