Chapter 7. Understanding application migration changes This section describes the changes required for migrating an application from JBoss EAP 6.4 or 7.x to JBoss EAP 8.0. 7.1. Web services application changes JBossWS 5 brings new features and performance improvements to JBoss EAP 7 web services, mainly through upgrades of the Apache CXF , Apache WSS4J , and Apache Santuario components. JBoss EAP 8.0 then uses JBossWS 7 to support its features. 7.1.1. JAX-RPC support changes The Java API for XML-based RPC (JAX-RPC) was deprecated in Java EE 6 and was optional in Java EE 7. Starting with JBoss EAP 7, it is no longer supported. Applications that use JAX-RPC must be migrated to use Jakarta XML Web Services , which is the current Jakarta EE standard web services framework. Use of JAX-RPC web services can be identified in any of the following ways: The presence of a JAX-RPC mapping file, which is an XML file with the root element <java-wsdl-mapping> . The presence of a webservices.xml XML descriptor file that contains a <webservice-description> element, which includes a <jaxrpc-mapping-file> child element. The following is an example of webservices.xml descriptor file that defines a JAX-RPC web service. <webservices xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1"> <webservice-description> <webservice-description-name>HelloService</webservice-description-name> <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file> <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file> <port-component> <port-component-name>Hello</port-component-name> <wsdl-port>HelloPort</wsdl-port> <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface> <service-impl-bean> <servlet-link>HelloWorldServlet</servlet-link> </service-impl-bean> </port-component> </webservice-description> </webservices> The presence of an ejb-jar.xml file, which contains a <service-ref> that references a JAX-RPC mapping file. 7.1.2. Apache CXF Spring web services changes In releases of JBoss EAP, you could customize the JBossWS and Apache CXF integration by including a jbossws-cxf.xml configuration file with the endpoint deployment archive. One use case for this was to configure interceptor chains for web service client and server endpoints on the Apache CXF bus. This integration required Spring to be deployed in the JBoss EAP server. Spring integration is no longer supported in JBoss EAP 8. Any application that contains a jbossws-cxf.xml descriptor configuration file must be modified to replace the custom configuration defined in that file. While it is still possible to directly access the Apache CXF API, be aware that the application will not be portable. The suggested approach is to replace Spring custom configurations with the new JBossWS descriptor configuration options where possible. The JBossWS descriptor-based approach provides similar functionality without requiring modification of the client endpoint code. In some cases, you can replace Spring with Context Dependency Injection (CDI). 7.1.2.1. Apache CXF interceptors The JBossWS descriptor provides new configuration options that allow you to declare the interceptors without modifying the client endpoint code. Instead you declare interceptors within predefined client and endpoint configurations by specifying a list of interceptor class names for the cxf.interceptors.in and cxf.interceptors.out properties. The following is an example of a jaxws-endpoint-config.xml file that declares interceptors using these properties. <?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd"> <endpoint-config> <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name> <property> <property-name>cxf.interceptors.in</property-name> <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value> </property> <property> <property-name>cxf.interceptors.out</property-name> <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value> </property> </endpoint-config> </jaxws-config> 7.1.2.2. Apache CXF features The JBossWS descriptor allows you to declare features within predefined client and endpoint configurations by specifying a list of feature class names for the cxf.features property. The following is an example of a jaxws-endpoint-config.xml file that declares a feature using this property. <?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd"> <endpoint-config> <config-name>Custom FI Config</config-name> <property> <property-name>cxf.features</property-name> <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value> </property> </endpoint-config> </jaxws-config> 7.1.2.3. Apache CXF HTTP transport In Apache CXF, HTTP transport configuration is achieved by specifying org.apache.cxf.transport.http.HTTPConduit options. JBossWS integration allows conduits to be modified programmatically using the Apache CXF API as follows. import org.apache.cxf.frontend.ClientProxy; import org.apache.cxf.transport.http.HTTPConduit; import org.apache.cxf.transports.http.configuration.HTTPClientPolicy; // Set chunking threshold before using a JAX-WS port client ... HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit(); HTTPClientPolicy client = conduit.getClient(); client.setChunkingThreshold(8192); ... You can also control and override the Apache CXF HTTPConduit default values by setting system properties. Property Type Description cxf.client.allowChunking Boolean Specifies whether to send requests using chunking. cxf.client.chunkingThreshold Integer Sets the threshold at which switching from non-chunking to chunking mode. cxf.client.connectionTimeout Long Sets the number of milliseconds for the connection timeout. cxf.client.receiveTimeout Long Sets the number of milliseconds for the receive timeout. cxf.client.connection String Specifies whether to use the Keep-Alive or close connection type. cxf.tls-client.disableCNCheck Boolean Specifies whether to disable the CN host name check. 7.1.3. WS-Security changes This section describes the various WS-Security changes for your application in JBoss EAP 6.4 and JBoss EAP 7.0. If your application contains a custom callback handler that accesses the org.apache.ws.security.WSPasswordCallback class, be aware that this class has moved to package org.apache.wss4j.common.ext . Most of the SAML bean objects from the org.apache.ws.security.saml.ext package have been moved to the org.apache.wss4j.common.saml package. Usage of the RSA v1.5 key transport and all related algorithms are disallowed by default. The Security Token Service (STS) previously only validated onBehalfOf tokens. It now also validates ActAs tokens. As a consequence, a valid username and password must be specified in the UsernameToken that is provided for the ActAs token. SAML Bearer tokens are now required to have an internal signature. The org.apache.wss4j.dom.validate.SamlAssertionValidator class now has a setRequireBearerSignature() method to enable or disable the signature verification. 7.1.4. JBoss modules structure change The cxf-api and cxf-rt-core JARs have been merged into one cxf-core JAR. As a consequence, the org.apache.cxf module in JBoss EAP now contains the cxf-core JAR and exposes more classes than in the release. 7.1.5. Bouncy Castle requirements and changes If you want to use AES encryption with Galois/Counter Mode (GCM) for symmetric encryption in XML/WS-Security, you need the BouncyCastle Security Provider. Starting with JBoss EAP 7, it was included with the org.bouncycastle module and JBossWS was able to rely on its class loader to get and use the BouncyCastle Security Provider. Therefore it is no longer necessary to statically install BouncyCastle in the current JVM. For applications running outside of the container, the security provider can be made available to JBossWS by adding a BouncyCastle library to the class path. You can disable this behavior by setting the org.jboss.ws.cxf.noLocalBC property value to true in the jaxws-endpoint-config.xml deployment descriptor file for the server or the jaxws-client-config.xml descriptor file for clients. If you want to use a different version than the one that ships with JBoss EAP, you can still statically install BouncyCastle to the JVM. In that case, the statically installed BouncyCastle Security Provider is chosen over the provider present in the class path. To avoid any issues, you must use BouncyCastle 1.72 or greater. 7.1.6. Apache CXF bus selection strategy The default bus selection strategy for clients running in-container has changed from THREAD_BUS to TCCL_BUS . For clients running out-of container, the default strategy is still THREAD_BUS . You can restore the behavior to that of the release by using either of the following methods. Boot the JBoss EAP server with the system property org.jboss.ws.cxf.jaxws-client.bus.strategy value set to THREAD_BUS . Explicitly set the selection strategy in the client code. 7.1.7. Jakarta XML Web Services 2.2 requirements for WebServiceRef Containers must use Jakarta XML Web Services 2.2 style constructors, which include the WebServiceFeature class as an argument in the constructor, to build clients that are injected into web service references. JBoss EAP 6.4, which ships with JBossWS 4, hides that requirement. Starting with JBoss EAP 7 that included JBossWS 5, this requirement is not hidden. This states that user provided service classes injected by the container must implement Jakarta XML Web Services 2.2 or later by updating the existing code to use the jakarta.xml.ws.Service constructor that includes one or more WebServiceFeature arguments. protected Service(URL wsdlDocumentLocation, QName serviceName, WebServiceFeature... features) 7.1.8. IgnoreHttpsHost CN check change In releases, you could disable the HTTPS URL hostname check against a service's Common Name (CN) given in its certificate by setting the system property org.jboss.security.ignoreHttpsHost to true . This system property name has been replaced with cxf.tls-client.disableCNCheck . 7.1.9. Server-side configuration and class loading As a consequence of enabling injections into service endpoint and service client handlers, it is no longer possible to automatically load handler classes from the org.jboss.as.webservices.server.integration JBoss module. If your application depends on a given predefined configuration, you might need to explicitly define new module dependencies for your deployment. For more information, see Migrate explicit module dependencies . 7.1.10. Deprecation of Java-endorsed standards override mechanism The Java-endorsed standards override mechanism was deprecated in JDK 1.8_40 with intent to remove it in JDK 9. This mechanism allowed developers to make libraries available to all deployed applications by placing JARs into an endorsed directory within the JRE. Starting with the JBoss EAP 7 release, if your application used the JBossWS implementation of Apache CXF, it ensured that the required dependencies are added in the correct order and you should not be impacted by this change. If your application accesses Apache CXF directly, you must now provide the Apache CXF dependencies after the JBossWS dependencies as part of your application deployment. 7.1.11. Specification of descriptor in EAR archive In releases of JBoss EAP, you could configure the jboss-webservices.xml deployment descriptor file for Jakarta Enterprise Beans web service deployments in the META-INF/ directory of JAR archives or in the WEB-INF/ directory for POJO web service deployments and Jakarta Enterprise Beans web service endpoints bundled in WAR archives. Starting with JBoss EAP 7, you can configure the jboss-webservices.xml deployment descriptor file in the META-INF/ directory of an EAR archive. If a jboss-webservices.xml file is found in the EAR archive and the JAR or WAR archive, the configuration data in the jboss-webservices.xml file for the JAR or WAR overrides the corresponding data in the EAR descriptor file. 7.2. Update the Remote URL connector and port Starting with JBoss EAP 7, the default connector has been changed from remote to http-remoting and the default remote connection port has changed from 4447 to 8080 . The JNDI provider URL for the default configuration has changed from remote://localhost:4447 to http-remoting://localhost:8080 . 7.3. Messaging application changes This section describes the various messaging application changes in JBoss EAP 7. In addition, you can learn more about how to: Change Jakarta Messaging deployment descriptors Update external Jakarta Messaging clients Replace deprecated address setting attributes Configure the required messaging application changes 7.3.1. Replace or update Jakarta Messaging deployment descriptors Starting with JBoss EAP 7, the proprietary HornetQ messaging resource deployment descriptor files identified by the naming pattern -jms.xml does not work. The following is an example of a Java Message Service resource deployment descriptor file in JBoss EAP 6: <?xml version="1.0" encoding="UTF-8"?> <messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0"> <hornetq-server> <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations> </hornetq-server> </messaging-deployment> If you used -jms.xml Java Message Service deployment descriptors in your application in the release, you can either convert your application to use the standard deployment descriptor as specified in the Resource Definition and Configuration section of the Jakarta EE platform , or you can update the deployment descriptor to use the messaging-activemq-deployment schema instead. If you choose to update the descriptor, you need to make the following modifications: Change the namespace from "urn:jboss:messaging-deployment:1.0" to "urn:jboss:messaging-activemq-deployment:1.0". Change the <hornetq-server> element name to <server> . The modified file should look like the following example. <?xml version="1.0" encoding="UTF-8"?> <messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0"> <server> <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations> </server> </messaging-deployment> 7.3.2. Replace the HornetQ API JBoss EAP 6 included the org.hornetq module, which allowed you to use the HornetQ API in your application source code. Apache ActiveMQ Artemis replaces HornetQ in JBoss EAP 7, so you must migrate any code that used the HornetQ API to use the Apache ActiveMQ Artemis API . The libraries for this API are included in the org.apache.activemq.artemis module. ActiveMQ Artemis is an evolution of HornetQ, so many of the concepts still apply. 7.3.3. Replace Deprecated Address Setting Attributes The ability to auto-create and auto-delete topics and queues using the auto-create-jms-queues , auto-delete-jms-queues , auto-create-jms-topics , and auto-delete-jms-topics attributes was only partially implemented and not fully configurable in JBoss EAP 7. These attributes, which are deprecated, were provided as a technology preview feature only and were not supported. You must replace any usage of these deprecated attributes with the following replacement attributes. Note The deprecated attributes no longer configure this functionality since JBoss EAP 8.0 and do not take effect. The replacement attributes are not supported either. They are provided only as a way to migrate on the best effort basis. Deprecated Attribute Replacement Attribute auto-create-jms-queues auto-create-queues auto-delete-jms-queues auto-delete-queues auto-create-jms-topics auto-create-addresses auto-delete-jms-topics auto-delete-addresses In JBoss EAP 6, the default address setting attributes were set to false . Starting with JBoss EAP 7, the replacement attributes are set to true by default. If you prefer to preserve the JBoss EAP 6 behavior, you must set the replacement attributes to false . For more information about these replacement attributes, see Address Setting Attributes in the JBoss EAP 7.4 Configuring Messaging Guide . 7.3.4. Messaging application changes required for JBoss EAP 7 Starting with JBoss EAP 7.2, if a client application directly depends on Artemis client JARs, for example, artemis-jms-client , artemis-commons , artemis-core-client , or artemis-selector , then you must add the following dependency in your pom.xml file for wildfly-client-properties . <dependency> <groupId>org.jboss.eap</groupId> <artifactId>wildfly-client-properties</artifactId> </dependency> This is to avoid a JMSRuntimeException when calling message.getJMSReplyTo() from an older JBoss EAP 7 client as described in JBEAP-15889 . 7.4. Jakarta RESTful Web Services and RESTEasy application changes JBoss EAP 6 bundled RESTEasy 2, which was an implementation of JAX-RS 1.x. JBoss EAP 7 and JBoss EAP 7.1 included RESTEasy 3.0.x, which is an implementation of JAX-RS 2.0 as defined by the JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services specification. JBoss EAP 7.4 includes RESTEasy 3.15, which is an implementation of Jakarta RESTful Web Services 2.1 . This release also adds support for JDK 11. While providing some of the RESTEasy 4 key features, this release is based on RESTEasy 3.0, ensuring full backward compatibility. As a result, you should encounter few issues when migrating from RESTEasy 3.0 to RESTEasy 3.15. For more information about the Java API for RESTEasy RESTEasy 3.15, see RESTEasy Jakarta RESTful Web Services 3.15.0.Final API . JBoss EAP 8.0 provides support for RESTEasy 6.2, which implements the Jakarta RESTful Web Services 3.1 specification . If you are migrating from JBoss EAP 6.4, be aware that the version of Jackson included in JBoss EAP has changed. JBoss EAP 6.4 included Jackson 1.9.9. JBoss EAP 7 and later now include Jackson 2.6.3 or greater. This section describes how these changes might impact applications that use RESTEasy or Jakarta RESTful Web Services. 7.4.1. RESTEasy deprecated classes Interceptor and MessageBody Classes JSR 311: JAX-RS: The JavaTM API for RESTful Web Services did not include an interceptor framework, so RESTEasy 2 provided one. JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services introduced an official interceptor and filter framework, so the interceptor framework included in RESTEasy 2 is now deprecated, and was replaced by the Jakarta REST compliant interceptor facility in RESTEasy 3.x. The relevant interfaces are defined in the jakarta.ws.rs.ext package of the jakarta.ws.rs.api module. The following providers have been removed in JBoss EAP 8.0: org.jboss.resteasy:resteasy-jackson-provider org.jboss.resteasy:resteasy-jettison-provider org.jboss.resteasy:resteasy-yaml-provider The following has been removed in JBoss EAP 8.0 as they now have Jakarta RESTful Web Services replacements. @Suspend and org.jboss.resteasy.spi.AsynchronousResponse have been removed and replaced with @Suspended and javax.ws.rs.container.AsyncResponse respectively. StringConverter is replaced by a ParamConverter . org.jboss.resteasy.plugins.providers.SerializableProvider was deprecated and has been removed. The following interceptor interfaces deprecated in RESTEasy 3.x has been removed. org.jboss.resteasy.spi.interception.PreProcessInterceptor org.jboss.resteasy.spi.interception.PostProcessInterceptor org.jboss.resteasy.spi.interception.ClientExecutionInterceptor org.jboss.resteasy.spi.interception.ClientExecutionContext org.jboss.resteasy.spi.interception.AcceptedByMethod The org.jboss.resteasy.spi.interception.PreProcessInterceptor interface was replaced by the jakarta.ws.rs.container.ContainerRequestFilter interface in RESTEasy 3.x. The following interfaces and classes have been removed from RESTEasy 3.x and JBoss EAP 8.0. org.jboss.resteasy.spi.interception.MessageBodyReaderInterceptor org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor org.jboss.resteasy.spi.interception.MessageBodyWriterContext org.jboss.resteasy.spi.interception.MessageBodyReaderContext org.jboss.resteasy.core.interception.InterceptorRegistry org.jboss.resteasy.core.interception.InterceptorRegistryListener org.jboss.resteasy.core.interception.ClientExecutionContextImpl The org.jboss.resteasy.spi.interception.MessageBodyWriterInterceptor interface was replaced by the jakarta.ws.rs.ext.WriterInterceptor interface. In addition, some changes to the jakarta.ws.rs.ext.MessageBodyWriter interface might not be backward compatible with respect to JAX-RS 1.x. If your application used JAX-RS 1.x, review your application code to make sure you define @Produces or @Consumes for your endpoints. Failure to do so might result in an error similar to the following. The following is an example of a REST endpoint that can cause this error. @Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } } To fix the issue, add the import for jakarta.ws.rs.Produces and the @Produces annotation as follows. ... import jakarta.ws.rs.Produces; ... @Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") @Produces(MediaType.TEXT_PLAIN) public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } } Note All interceptors from the release of RESTEasy can run in parallel with the new Jakarta REST filter and interceptor interfaces. Additional resources RESTEasy Interceptors RESTEasy Jakarta RESTful Web Services 3.15.0.Final API Client API The RESTEasy client framework in resteasy-jaxrs was replaced by the JAX-RS 2.0 compliant resteasy-client module in JBoss EAP 7.0. As a result, some RESTEasy client API classes and methods are deprecated. The following classes have been removed from JBoss EAP 8.0. org.jboss.resteasy.client.ClientRequest org.jboss.resteasy.client.ClientRequestFactory org.jboss.resteasy.client.ClientResponse org.jboss.resteasy.client.ProxyBuilder org.jboss.resteasy.client.ProxyConfig org.jboss.resteasy.client.ProxyFactory The org.jboss.resteasy.client.ClientResponseFailure exception and the org.jboss.resteasy.client.ClientExecutor and org.jboss.resteasy.client.EntityTypeFactory interfaces are also deprecated. You must replace the org.jboss.resteasy.client.ClientRequest and org.jboss.resteasy.client.ClientResponse classes with org.jboss.resteasy.client.jaxrs.ResteasyClient and jakarta.ws.rs.core.Response respectively. The following is an example of how to send a link header with the RESTEasy client in RESTEasy 2.3.x. ClientRequest request = new ClientRequest(generateURL("/linkheader/str")); request.addLink(" chapter", "", "http://example.com/TheBook/chapter2", null); ClientResponse response = request.post(); LinkHeader header = response.getLinkHeader(); The following is an example of how to accomplish the same task with the RESTEasy client in RESTEasy 3. ResteasyClient client = new ResteasyClientBuilder().build(); Response response = client.target(generateURL("/linkheader/str")).request() .header("Link", "<http://example.com/TheBook/chapter2>; rel=\"\"; title=\" chapter\"").post(Entity.text(new String())); jakarta.ws.rs.core.Link link = response.getLink(""); See the resteasy-jaxrs-client quickstart for an example of an external Jakarta REST RESTEasy client that interacts with a Jakarta REST Web service. The classes and interfaces in the org.jboss.resteasy.client.cache package are also deprecated. They are replaced by equivalent classes and interfaces in the org.jboss.resteasy.annotations.cache package. Note For more information about the org.jboss.resteasy.client.jaxrs API classes, see the RESTEasy Jakarta REST JavaDoc . StringConverter The org.jboss.resteasy.spi.StringConverter class is deprecated in RESTEasy 3.x and JBoss EAP 8.0. This functionality can be replaced using the Jakarta REST jakarta.ws.rs.ext.ParamConverterProvider class. 7.4.2. Removed or Protected RESTEasy classes ResteasyProviderFactory Add methods Most of the org.jboss.resteasy.spi.ResteasyProviderFactory add() methods have been removed or made protected in RESTEasy 3.0. For example, the addBuiltInMessageBodyReader() and addBuiltInMessageBodyWriter() methods have been removed and the addMessageBodyReader() and addMessageBodyWriter() methods have been made protected. You should now use the registerProvider() and registerProviderInstance() methods. Additional Classes Removed From RESTEasy 3 The @org.jboss.resteasy.annotations.cache.ServerCached annotation, which specified the response to the Jakarta REST method should be cached on the server, was removed from RESTEasy 3 and must be removed from the application code. 7.4.3. Additional RESTEasy changes This section provides information about some additional changes in RESTEasy for JBoss EAP. SignedInput and SignedOuput SignedInput and SignedOutput for resteasy-crypto must have the Content-Type set to multipart/signed in either the Request or Response object, or by using the @Consumes or @Produces annotation. You can use SignedOutput and SignedInput to return the application/pkcs7-signature MIME type format in binary form by setting that type in the @Produces or @Consumes annotations. If the @Produces or @Consumes is text/plain MIME type, SignedOutput will be base64 encoded and sent as a String. Security Filters The security filters for @RolesAllowed , @PermitAll , and @DenyAll now return "403 Forbidden" instead of "401 Unauthorized". Client-side Filters The client-side filters that were introduced in JAX-RS 2.0 will not be bound and run when you are using the RESTEasy client API from a release prior to RESTEasy 3.0. Asynchronous HTTP Support Because the JAX-RS 2.0 specification added asynchronous HTTP support using the @Suspended annotation and the AsynResponse interface, the RESTEasy proprietary API for asynchronous HTTP was deprecated and might be removed in a future RESTEasy release. The asynchronous Tomcat and asynchronous JBoss Web modules have also been removed from the server installation. If you are not using the Servlet 3.0 container or higher, asynchronous HTTP server-side processing will be simulated and run synchronously in same request thread. Server-side Cache Server-side cache setup has changed. Please see the RESTEasy Documentation for more information. YAML Provider Setting Changes In releases of JBoss EAP, the RESTEasy YAML provider setting was enabled by default. This has changed in JBoss EAP 7. The YAML provider is now disabled by default. Its use is not supported due to a security issue in the SnakeYAML library used by RESTEasy for unmarshalling and it must be explicitly enabled in the application. For information about how to enable the YAML provider in your application and add the Maven dependencies, see YAML Provider in JBoss EAP 7.4 Developing Web Services Applications . Default Charset UTF-8 in Content-Type Header As of JBoss EAP 7.1, the resteasy.add.charset parameter is set to true by default. You can set the resteasy.add.charset parameter to false if you do not want RESTEasy to add charset=UTF-8 to the returned content-type header when the resource method returns a text/* or application/xml* media type without an explicit charset. For more information about text media types and character sets, see Text Media Types and Character Sets in JBoss EAP 7.4 Developing Web Services Applications . SerializableProvider Deserializing Java objects from untrusted sources is not safe. For this reason, starting with JBoss EAP 7, the org.jboss.resteasy.plugins.providers.SerializableProvider class is disabled by default, and it is not recommended to use this provider. Matching Requests to Resource Methods In RESTEasy 3, improvements and corrections were made to the implementation of matching rules, as defined in the JAX-RS specification. In particular, a change was made to how an ambiguous URI on a sub-resource method and a sub-resource locator is handled. In RESTEasy 2, it was possible for a sub-resource locator to execute successfully even when there was another sub-resource with the same URI. This behavior was incorrect according to the specification. In RESTEasy 3, when there is an ambiguous URI for a sub-resource and a sub-resource locator, calling the sub-resource will be successful; however, calling the sub-resource locator will result in an HTTP status 405 Method Not Allowed error. The following example contains an ambiguous @Path annotation on a sub-resource method and a sub-resource locator. Notice that the URI to both endpoints, anotherResource and anotherResourceLocator , is the same. The difference between the two endpoints is that the anotherResource method is associated with the REST verb, POST . The anotherResourceLocator method is not associated with any REST verb. According to the specification, the endpoint with the REST verb, in this case the anotherResource method, will always be selected. @Path("myResource") public class ExampleSubResources { @POST @Path("items") @Produces("text/plain") public Response anotherResource(String text) { return Response.ok("ok").build(); } @Path("items") @Produces("text/plain") public SubResource anotherResourceLocator() { return new SubResource(); } } 7.4.4. RESTEasy SPI changes The RESTEasy SPI provider has been removed in JBoss EAP 8. SPI Exceptions All SPI failure exceptions were deprecated and are no longer used internally. They have been replaced with the corresponding Jakarta REST exception. Deprecated Exception Replacement Exception in jaxrs-api module org.jboss.resteasy.spi.ForbiddenException jakarta.ws.rs.ForbiddenException org.jboss.resteasy.spi.MethodNotAllowedException jakarta.ws.rs.NotAllowedException org.jboss.resteasy.spi.NotAcceptableException jakarta.ws.rs.NotAcceptableException org.jboss.resteasy.spi.NotFoundException jakarta.ws.rs.NotFoundException org.jboss.resteasy.spi.UnauthorizedException jakarta.ws.rs.NotAuthorizedException org.jboss.resteasy.spi.UnsupportedMediaTypeException jakarta.ws.rs.NotSupportedException InjectorFactory and Registry The InjectorFactory and Registry SPIs have changed. This should not be an issue if you use RESTEasy as documented and supported. 7.4.5. Jackson provider changes The version of Jackson included in JBoss EAP 6.4 has changed. Starting with JBoss EAP 7, the Jackson provider has changed from resteasy-jackson-provider to resteasy-jackson2-provider . The upgrade to the resteasy-jackson2-provider requires some package changes. For example, the Jackson annotation package has changed from org.codehaus.jackson.annotate to com.fasterxml.jackson.annotation . 7.4.6. Spring RESTEasy integration changes JBoss EAP 8.0 provides support for RESTEasy 6.2. If you plan to use the Spring 6.0 framework with JBoss EAP 8.0, you must use Java 17. The Spring 4.0 framework introduced support for Java 8. If you plan to use the RESTEasy 3.x integration with Spring, be sure to specify 4.2.x as the minimum Spring version in your deployment as this is the earliest stable version supported by JBoss EAP 7. 7.4.7. RESTEasy Jettison JSON provider changes The RESTEasy Jettison JSON provider is deprecated since JBoss EAP 7 and is no longer added to deployments by default. You are encouraged to switch to the recommended RESTEasy Jackson provider. If you prefer to continue to use the Jettison provider, you must define an explicit dependency for it in the jboss-deployment-descriptor.xml file as demonstrated in the following example. <?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <exclusions> <module name="org.jboss.resteasy.resteasy-jackson2-provider"/> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> </exclusions> <dependencies> <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/> </dependencies> </deployment> </jboss-deployment-structure> For more information about how to define explicit dependencies, see Add an Explicit Module Dependency to a Deployment in the JBoss EAP 7.4 Development Guide . 7.4.8. MicroProfile for JBoss EAP MicroProfile is the name of a specification that developers can use to configure applications and microservices to run in multiple environments without having to modify or repackage those apps. Previously, MicroProfile was available for JBoss EAP 7.3 as a technology preview, but it has since been removed. MicroProfile is now available only on JBoss EAP XP. Additional resources Understand MicroProfile 7.5. CDI application changes JBoss EAP 8.0 includes support for CDI 4.0. As a result, applications written using older CDI releases might see some changes in behavior when migrating to JBoss EAP 8.0. This section summarizes only a few of these changes. For more information about Weld and CDI 4.0, see: Jakarta Context Dependency Injection 4.0 Weld 5.1.1.Final - CDI Reference Implementation 7.5.1. Bean Archives Bean classes of enabled beans must be deployed in bean archives to ensure they are discovered by CDI and processed as beans. CDI 1.1 introduced implicit bean archives, which are archives that contain one or more bean classes with a bean defining annotation, or one or more session beans. Implicit bean archives are scanned by CDI and, during type discovery, only classes with bean defining annotations are discovered. For more information, see Type and Bean Discovery in JSR 365: Contexts and Dependency Injection for Java TM 2.0 . The Jakarta equivalents for bean defining annotations are defined in the Jakarta Context Dependency Injection 2.0 specification . In CDI 4.0: An archive does not differentiate whether beans.xml has a version number. In addition to build-compatible extensions, an archive also contains archives without the beans.xml file. The build compatible extensions are not bean archives. The default discovery mode of an archive with an empty beans.xml file is set to annotated instead of all . For example, if the beans.xml file is empty, it is an implicit bean archive instead of an explicit bean archive. In both cases, the bean discovery element is unaffected between archives with and without beans.xml files. For more information about CDI 4.0, see Jakarta Contexts and Dependency Injection 4.0 . A bean archive has a bean discovery mode of all , annotated or none . A bean archive which contains non-empty beans.xml must specify the bean-discovery-mode attribute. The default value for the attribute is annotated . An archive is not a bean archive in the following cases: It contains a beans.xml file with a bean-discovery-mode of none . It contains a portable extension or a build compatible extension and no beans.xml file. An archive is an explicit bean archive in the following case: The archive contains a beans.xml file with bean-discovery-mode of all . An archive is an implicit bean archive in the following cases: The archive contains a beans.xml file that is empty. The archive contains one or more bean classes with a bean defining annotation, or one or more session beans, even if it does not contain a beans.xml file. CDI 1.2 limited bean defining annotations to the following: @ApplicationScoped , @SessionScoped , @ConversationScoped , and @RequestScoped annotations All other normal scope types @Interceptor and @Decorator annotations All stereotype annotations, which are annotations annotated with @Stereotype @Dependent scope annotation 7.5.2. Clarification of Conversation Resolution The conversation context lifecycle was changed in CDI 1.2 to prevent conflicts with the Servlet specification as described in CDI Specification Issue CDI-411 . The conversation scope is active during all servlet requests and should not prevent other servlets or servlet filters from setting the request body or character encoding. For more information, see Conversation context lifecycle in Jakarta EE . 7.5.3. Observer Resolution Event resolution was partly rewritten in CDI 1.2. In CDI 1.0, an event is delivered to an observer method if the observer method has all the event qualifiers. In CDI 1.2, an event is delivered to an observer method if the observer method has no event qualifiers or has a subset of the event qualifiers. For more information, see Observer resolution . 7.6. HTTP Session ID change The string returned by the request.getSession().getId() call to get the unique identifier assigned to an HTTP session has changed between JBoss EAP 6.4 and JBoss EAP 7. JBoss EAP 6.4 returned both the session ID and the instance ID in the session-id.instance-id format. JBoss EAP 7 and EAP 8 returns only the session ID. This change can create issues with routeless cookies for some upgrades from JBoss EAP 6 to JBoss EAP 8. If your application recreates JSESSIONID cookies based upon the return value from this method call, you might need to update the application code to provide the desired behavior. 7.7. Migrate explicit module dependencies The introduction of the modular class loading system and JBoss Modules in the release of JBoss EAP allowed for fine-grained control of the classes available to applications. This feature allowed you to configure explicit module dependencies using the application's MANIFEST.MF file or the jboss-deployment-structure.xml deployment descriptor file. If you defined explicit module dependencies in your application, you should be aware of the following changes in JBoss EAP 7. Review Dependencies for Availability The modules that are included in JBoss EAP have changed. When you migrate your application to JBoss EAP 7, review your MANIFEST.MF and jboss-deployment-structure.xml file entries to make sure they do not refer to any modules that were removed or are deprecated in this release of the product. Dependencies That Require Annotation Scanning In the release of JBoss EAP, if your dependency contained annotations that needed to be processed during annotation scanning, such as when declaring EJB Interceptors, you were required to generate and include a Jandex index in a new JAR file and then set a flag in the MANIFEST.MF or jboss-deployment-structure.xml deployment descriptor file. JBoss EAP 7 now provides automatic runtime generation of annotation indexes for static modules, so you no longer need to generate them manually. However, you still need to add the annotations flag to the application's MANIFEST.MF file or the jboss-deployment-structure.xml deployment descriptor file as demonstrated below. Example: Annotation Flag in the MANIFEST.MF File Example: Annotation Flag in the jboss-deployment-structure.xml File <jboss-deployment-structure> <deployment> <dependencies> <module name="com.company.my-ejb" annotations="true"/> <module name="com.company.other"/> </dependencies> </deployment> </jboss-deployment-structure> 7.8. Hibernate changes JBoss EAP 8 includes support for Hibernate ORM 6.2, an object-relational mapping tool for the Java programming language. For more information about the Hibernate ORM 6.2 documentation, see Hibernate ORM 6.2 . When migrating from JBoss EAP 7.4 to JBoss EAP EAP 8.0, refer to the specific Hibernate ORM migration documentation for your Hibernate ORM version. For migrating from JBoss EAP 7.4 to JBoss EAP 8, you must complete the following steps. Migrating from Hibernate ORM 5.3 to 5.4 Migrating from Hibernate ORM 5.4 to 5.5 Migrating from Hibernate ORM 5.5 to 5.6 Migrating from Hibernate ORM 5.6 to 6.0 Migrating from Hibernate ORM 6.0 to 6.1 Migrating from Hibernate ORM 6.1 to 6.2 Hibernate ORM dialects Deprecated Hibernate ORM classes Incubating Hibernate ORM classes Hibernate ORM internals For migrating from older versions of JBoss EAP and Hibernate, you must complete the following steps. Migrating from Hibernate ORM 4.3 to Hibernate ORM 5.0 Migrating from Hibernate ORM 5.0 to Hibernate ORM 5.1 Migrating from Hibernate ORM 5.1 and Hibernate ORM 5.2 to Hibernate ORM 5.3 Additional resources Hibernate ORM 6.2 Dialects Deprecated Hibernate ORM classes Incubating Hibernate ORM classes Hibernate ORM internals 7.8.1. Migrating from Hibernate ORM 5.3 to 5.4 This section highlights the changes required when migrating from Hibernate ORM version 5.3 to 5.4. For more information about the changes implemented between Hibernate ORM 5.3 and Hibernate ORM 5.4, see the Hibernate ORM 5.4 Migration Guide . Known Changes The following describes some of the changes when migrating from Hibernate ORM version 5.3 to 5.4. 7.8.1.1. Overriding Delayed Identity Insert Behavior In Hibernate 5.3, support was provided for DelayedPostInsertIdentifier behavior to be influenced based on the FlushMode or FlushModeType values, in short enhancing Extended PersistenceContext support. Unfortunately, there were a few issues that were included in this change. In Hibernate 5.4, it was decided to preserve as much of the Hibernate 5.3 behavior as possible and only restore very specific DelayedPostInsertIdentifier behavior for selected use cases. In order to make Hibernate 5.4 more flexible, a configuration option was added to be used as a temporary solution to completely disable the Hibernate 5.3 behavior, reverting it back to Hibernate 5.2 and earlier. 7.8.1.2. SQL Server JDBC Driver version upgrade to at least 6.1.2 Due to fixing HHH-12973 , you must upgrade the JDBC Driver version to 6.1.2. Due to this issue, the older versions of the SQL Server JDBC Driver cannot introspect the INFORMATION_SCHEMA.SEQUENCES without closing the database connection. 7.8.2. Migrating from Hibernate ORM 5.4 to 5.5 This section highlights the changes required when migrating from Hibernate ORM version 5.4 to 5.5. For more information about the changes implemented between Hibernate ORM 5.4 and Hibernate ORM 5.5, see the Hibernate ORM 5.5 Migration Guide . Known Changes The Hibernate ORM 5.5 version is similar to Hibernate ORM 5.4 as it includes all bugfixes applied to the 5.4 maintenance releases and introduces support for Jakarta Persistence API. 7.8.2.1. Dom4J based XML mapping The implementation of Hibernate's parsing of XML mapping definitions has been compleltey reworked based on JAXB rather than DOM4J, to ensure continous progress for removing this dependecy. 7.8.2.2. Removed the ability to disable "enhanced proxies" The "enhanced proxies" feature had been introduced as an optional performance improvement feature for Hibernate 5.3. This feature is now enabled permanently. 7.8.3. Migrating from Hibernate ORM 5.5 to 5.6 This section highlights the changes required when migrating from Hibernate ORM version 5.5 to 5.6. For more information about the changes implemented between Hibernate ORM 5.5 and Hibernate ORM 5.6, see the Hibernate ORM 5.6 Migration Guide . Deprecated features The Hibernate 5.6 version is very similar to the Hibernate 5.5 version, with the exception of removal of some of the deprecated features from Hibernate releases. 7.8.3.1. Removal of Javassist You can no longer choose javassist as an implementation to be used for the bytecode enhancement of entities. Byte Buddy is the default, and javassist has been deprecated for some time and now removed. This does not have any functional impact on applications; the only exception being that it's not longer valid to configure the hibernate.bytecode.provider=javassist property . You can remove this property if you are using this feautre. It can cause an issue where Hibenate ORM no longer lists javassist among its dependencies. 7.8.4. Migrating from Hibernate ORM 5.6 to 6.0 This section highlights the changes required when migrating from Hibernate ORM version 5.6 to 6.0. For more information about the changes implemented between Hibernate ORM 5.6 and Hibernate ORM 6.0, see the Hibernate ORM 6.0 Migration Guide . The Hibernate 6.0 release includes the following changes: Java 11 is the minimum compatible baseline version for Hibernate 6.0. Jakarta Persistence: Another important change in the Hibernate ORM 6.0 release includes moving from the Java Persistence as defined by the Java EE specs to Jakarta Persistence as defined by the Jakarta EE spec. The most important impact resulting from this change includes the use of the Jakarata Persistence classes jakarta.persistence.* instead of the Java Persistence ones javax.persistence.* . Reading from JDBC: Another reason for the development of the Hibernate ORM 6.0 version was to move from reading results from the JDBC ResultSet by name (read-by-name) to reading the results by position (read-by-position). This change was made to improve the scaling by undertaking throughput testing. Generated SQL: This feature resulted in the following enhancements: Column aliases are no longer generated Column references are "unique-d". Better definition of joins and better determination of unnecessary joins (secondary tables, inheritance tables) Identifier as Object - The earlier versions of Hibernate required that all identifier types implement Serializable , Hibernate 6.0 has removed this restriction as identifiers can be any Object . This change affects many API and SPI methods previously defined using Serializable . @IdGeneratorType: With this release, you can use the @IdGeneratorType annotation for better type-safe way to define custom generators for identifier generation. Implicit Identifier Sequence and Table Name: The method by which Hibernate determines implicit names for sequences and tables associated with identifier generation has been modified in Hibernate 6.0, This may affect the user migrating applications. In this release, Hibernate creates a sequence per entity hierarchy instead of a single sequence hibernate_sequence by default. Defaults for implicit sequence generators: Implicit sequences, like the hibernate_sequence earlier now adhere to the default value of the JPA @SequenceGenerator annotation, which means that the sequences have an allocation size of 50. Type system: As Hibernate 6.0 is a major release, another important change was to modify Hibernate's mapping annotations and make them more type-safe. This feature was decided to be provided in this release as type-related contracts were already changing to implement the read-by-position changes. Query: A lot of changes have been introduced in the functionality for Query. Query features such as moving to a dedicated tree structure to model HQL and Criteria queries, improving the implementations for bulk SQM DML statements like insert, update, and delete, as well as changing the behavior of the hibernate.criteria.copy_tree property, and the inclusion of pass-through tokens have been introduced in this release. Signature change of the #onSave method: The signature of the #onSave method has been changed from boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) to boolean onSave(Object entity, Object id, Object[] state, String[] propertyNames, Type[] types) to accomadate the change of expected identifier type from Serializable to Object . Fetch circularity determination: versions of Hibernate determined fetches using a depth-first approach, which occasionally led to odd "circularity" determination. Starting with Hibernate 6.0, now fetch determination is performed using a width first approach. Restructuring of org.hibernate.loader: The contents of the loader.collection package were restructured into loader.ast.spi and loader.ast.internal as well as adapted to the SQM API. Restructuring of the SQL package: The contents of sql.ordering were moved to metamodel.mapping.ordering.ast . Deprecation of hbm.xml mappings: Legacy hbm.xml mapping format is deprecated and will no longer supported beyond 6.x. Lazy association adherance: Prior to Hibernate 6.0, lazy associations that used fetch="join" or @Fetch(FetchMode.JOIN) were considered eager when loaded by id i.e. through Session#get/EntityManager#find , even though for queries the association was treated as lazy. Starting with Hibernate 6.0, the laziness of such associations is properly respected, regardless of the fetch mechanism. Backwards compatibility can be achieved by specifying lazy="false" or @ManyToOne(fetch = EAGER)/@OneToOne(fetch = EAGER)/@OneToMany(fetch = EAGER)/@ManyToMany(fetch = EAGER) . Change of behavior for hbm.xml <return-join/> : As per Hibernate 6.0, a <return-join/>` cause an association to be fetched, rather than adding a selection item. For more information about these features, see Hibernate ORM 6.0 Migration Guide . The Hibernate 6.0 release contains also contains lot of feature removals from Hibernate releases, which are listed as follows: hbm.xml multiple <column/> is now disallowed - In 6.0 the support for basic property mappings with multiple columns was removed. The component class attribute now supports interpreting a CompositeUserType class properly. Legacy Hibernate Criteria API - The legacy Hibernate Criteria API which was deprecated back in Hibernate 5.x has been removed in Hibernate 6.0. Callable via NativeQuery - Using NativeQuery to call SQL functions and procedures is no longer supported. Use methods such as org.hibernate.procedure.ProcedureCall or jakarta.persistence.StoredProcedureQuery instead. HQL fetch all properties clause - The fetch all properties clause was removed from the HQL language. JMX integration - Hibernate no longer provides built-in support for integrating itself with JMX environments. JACC integration - Hibernate no longer provides built-in support for integrating itself with JACC environments. For more information about features removed in Hibernate 6.0, see Hibernate ORM 6.0 Migration Guide . 7.8.5. Migrating from Hibernate ORM 6.0 to 6.1 This section highlights the changes required when migrating from Hibernate ORM version 6.0 to 6.1. For more information about the changes implemented between Hibernate ORM 6.0 and Hibernate ORM 6.1, see the Hibernate ORM 6.1 Migration Guide . The Hibernate 6.1 release contains the following changes: Basic arrays: Basic arrays other than byte[]/Byte[] and char[]/Character[] , and basic collections (only subtypes of Collection) now map to the type code SqlTypes.ARRAY by default, which maps to the SQL standard array type as determined by the new methods getArrayTypeName and supportsStandardArrays of org.hibernate.dialect.Dialect . Enum mapping changes: Enums now map to the type code SqlType.SMALLINT by default, as before it mapped to TINYINT . This mapping was not quite correct as Java effectively allows up to 32K enum entries, but TINYINT is only a 1 byte type. For more detailed information about features included in the Hibernate 6.1, see the Hibernate ORM 6.1 Migration Guide . 7.8.6. Migrating from Hibernate ORM 6.1 to 6.2 This section highlights the changes required when migrating from Hibernate ORM version 6.1 to 6.2. For more information about the changes implemented between Hibernate ORM 6.1 and Hibernate ORM 6.2, see the Hibernate ORM 6.2 Migration Guide . The Hibernate 6.2 release contains the following enhancements, which are listed as follows: DDL type changes: OffsetTime mapping changes - In this release, OffsetTime depends on @TimeZoneStorage and the hibernate.timezone.default_storage setting. As the default setting is TimeZoneStorageType.DEFAULT , it means that the DDL expectations for such columns have changed. UUID mapping changes on MariaDB - On MariaDB, the type code SqlTypes.UUID by default refers to the DDL type uuid , as compared to before where it was using binary(16) . Due to this change, schema validation errors can occur on existing databases. UUID mapping changes on SQL Server - On SQL Server, the type code SqlTypes.UUID by default refers to the DDL type uniqueidentifier , as compared to before where it was using binary(16) . Due to this change, schema validation errors can occur on existing databases. JSON mapping changes on Oracle - On Oracle 12.1+, the type code SqlTypes.JSON by default refers to the DDL type blob and on 21+ to json, as compared to before where it was using clob . Due to this change, schema validation errors can occur on existing databases. JSON mapping changes on H2 - On H2 1.4.200+, the type code SqlTypes.JSON by default refers to the DDL type JSON, as compared to before where it was using clob . Due to this change, schema validation errors can occur on existing databases. Datatype for enums - Starting from Hibernate 6.2, the choice of implicit SQL datatype for storing enums is sensitive to the number of entries defined on the enum class. Timezone and offset storage - hibernate.timezone.default_storage now defaults to DEFAULT . Byte[]/Character[] mapping changes - Hibernate 6.2 makes it configurable to handle mapping of Byte[] and Character[] mapping changes in a domain model. UNIQUE constraint for optional one-to-one mappings - Earlier versions of Hibernate did not create a UNIQUE constraint on the database for logical one-to-one associations marked as optional . Starting in Hibernate 6.2, those UNIQUE constraints are now created. Column type inference for number(n,0) in native SQL queries on Oracle - Since Hibernate 6.0, columns of type number with scale 0 on Oracle were interpreted as boolean , tinyint , smallint , int , or bigint , depending on the precision. Now, columns of type number with scale 0 are interpreted as int or bigint depending on the precision. Removal of support for legacy database versions - Hibernate 6.2 introduces the concept of minimum supported database version for most of the database dialects that are supported by Hibernate. Changes to CDI handling - When CDI is available and configured, Hibernate can use the CDI BeanManager to resolve various bean references. Starting with Hibernate 6.2, these extensions will only be resolved from the CDI BeanManager if hibernate.cdi.extensions is set to true . Change in enhancement defaults and deprecation - The enableLazyInitialization and enableDirtyTracking enhancement tooling options, the global property hibernate.bytecode.use_reflection_optimizer as well as the respective hibernate.enhancer.enableLazyInitialization and hibernate.enhancer.enableDirtyTracking configuration settings, switched their default values to true and these settings are now deprecated. Package updates for org.hibernate.cfg and org.hibernate.loader : The org.hibernate.cfg and org.hibernate.loader packages have been updated to clearly display a distinction between contracts which are considered an API, SPI and internal. Changes in integration contracts (SPIs) - During the development of Hibernate ORM 6.2, the following SPIs have been modified: EntityPersister#lock , EntityPersister#multiLoad , Executable#afterDeserialize , and JdbcType#getJdbcRecommendedJavaTypeMapping() . Query Path comparison: As per Hibernate 6.2, comparisons of paths are type checked early. Batch Fetching and LockMode - When LockMode is greater than READ , Hibernate does not execute the batch fetching so existing uninitialized proxies will not be initialized. This is because the lock mode is different from one of the proxies in the batch fetch queue. 7.8.7. Migrating from Hibernate ORM 4.3 to Hibernate ORM 5.0 JBoss EAP 7.0 included Hibernate ORM 5.0. This section highlights the changes you need to make when migrating from Hibernate ORM version 4.3 to version 5. For more information about the changes implemented between Hibernate ORM 4 and Hibernate ORM 5, see the Hibernate ORM 5.0 Migration Guide . Removed and deprecated classes The following deprecated classes were removed from Hibernate ORM 5: org.hibernate.cfg.AnnotationConfiguration org.hibernate.id.TableGenerator org.hibernate.id.TableHiLoGenerator org.hibernate.id.SequenceGenerator Other changes to classes and packages The org.hibernate.integrator.spi.Integrator interface changed to account for bootstrap redesign. A new package org.hibernate.engine.jdbc.env.spi was created. It contains the org.hibernate.engine.jdbc.env.spi.JdbcEnvironment interface, which was extracted from the org.hibernate.engine.jdbc.spi.JdbcServices interface. A new org.hibernate.boot.model.relational.ExportableProducer interface was introduced that will affect org.hibernate.id.PersistentIdentifierGenerator implementations. The signature of org.hibernate.id.Configurable was changed to accept org.hibernate.service.ServiceRegistry rather than just org.hibernate.dialect.Dialect . The org.hibernate.metamodel.spi.TypeContributor interface has migrated to org.hibernate.boot.model.TypeContributor . The org.hibernate.metamodel.spi.TypeContributions interface has migrated to org.hibernate.boot.model.TypeContributions . Type handling Built-in org.hibernate.type.descriptor.sql.SqlTypeDescriptor implementations no longer auto-register themselves with org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry . Applications using custom SqlTypeDescriptor implementations that extend the built-in implementations and rely on that behavior must be updated to call SqlTypeDescriptorRegistry.addDescriptor() themselves. For IDs defined as generated UUIDs, some databases require you to explicitly set the @Column(length=16) in order to generate BINARY(16) so that comparisons work properly. For EnumType mappings defined in the hbm.xml , where you want javax.persistence.EnumType.STRING name-mapping , this configuration must be explicitly stated by using either the useNamed(true) setting or by specifying a VARCHAR value of 12 . Transaction management The transaction SPI underwent a major redesign in Hibernate ORM 5. In Hibernate ORM 4.3, you used the org.hibernate.Transaction API to directly access different back-end transaction strategies. Hibernate ORM 5 introduced a level of indirection. On the back end, the org.hibernate.Transaction implementation now talks to a org.hibernate.resource.transaction.TransactionCoordinator , which represents the transactional context for a given session according to the back-end strategy. While this does not have a direct impact on developers, it could affect the bootstrap configuration. Previously applications would specify hibernate.transaction.factory_class property, which is now deprecated, and refer to a org.hibernate.engine.transaction.spi.TransactionFactory FQN (fully qualified name). With Hibernate ORM 5, you specify the hibernate.transaction.coordinator_class setting and refer to a org.hibernate.resource.transaction.TransactionCoordinatorBuilder . See org.hibernate.cfg.AvailableSettings.TRANSACTION_COORDINATOR_STRATEGY for additional details. The following short names are now recognized: jdbc : Manage transactions using the JDBC java.sql.Connection . This is the default for non-Jakarta Persistence transactions. jta : Manage transactions using Jakarta Transactions. Important If a Jakarta Persistence application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate will automatically build the proper transaction coordinator based on the transaction type for the persistence unit. If a non-Jakarta Persistence application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate will default to jdbc to manage the transactions. This default will cause problems if the application actually uses Jakarta Transactions. A non-Jakarta Persistence application that uses Jakarta Transactions should explicitly set the hibernate.transaction.coordinator_class property value to jta or provide a custom org.hibernate.resource.transaction.TransactionCoordinatorBuilder that builds a org.hibernate.resource.transaction.TransactionCoordinator that properly coordinates with Jakarta Transactions. Other Hibernate ORM 5 changes The cfg.xml files are again fully parsed and integrated with events, security, and other functions. The properties loaded from the cfg.xml using the EntityManagerFactory did not previously prefix names with hibernate . This has now been made consistent. The configuration is no longer serializable. The org.hibernate.dialect.Dialect.getQuerySequencesString() method now retrieves catalog, schema, and increment values. The AuditConfiguration modifier was removed from org.hibernate.envers.boot.internal.EnversService . The AuditStrategy method parameters were changed to remove the obsolete AuditConfiguration and use the new EnversService . Various classes and interfaces in the org.hibernate.hql.spi package and subpackages have been moved to the new org.hibernate.hql.spi.id package. This includes the MultiTableBulkIdStrategy class and the AbstractTableBasedBulkIdHandler , TableBasedDeleteHandlerImpl , and TableBasedUpdateHandlerImpl interfaces and their subclasses. There was a complete redesign of property access contracts. Valid hibernate.cache.default_cache_concurrency_strategy setting values are now defined using the org.hibernate.cache.spi.access.AccessType.getExternalName() method rather than the org.hibernate.cache.spi.access.AccessType enum constants. This is more consistent with other Hibernate settings. 7.8.8. Migrating from Hibernate ORM 5.0 to Hibernate ORM 5.1 JBoss EAP 7.1 included Hibernate ORM 5.1. This section highlights the differences and the changes needed when migrating from Hibernate ORM version 5.0 to version 5.1. Hibernate ORM 5.1 features This release of Hibernate includes performance improvements and bug fixes. For more information, see Hibernate ORM 5.1 Features in the JBoss EAP Release notes for 7.1.0 . For additional information about the changes implemented between Hibernate ORM 5.0 and Hibernate ORM 5.1, see the Hibernate ORM 5.1 Migration Guide . Schema management tooling changes Schema management tooling changes in JBoss EAP 7 Schema management tooling changes in Hibernate ORM 5.1 are focused on the following areas: Unifying the handling of hbm2ddl.auto and support for hibernate's Jakarta Persistence schema-generation . Removing JDBC concerns from the SPI to facilitate true replacement for Hibernate OGM, a persistence engine that provides Jakarta Persistence support for NoSQL data stores. The schema management tooling changes are only a migration concern for applications that directly use the following classes: org.hibernate.tool.hbm2ddl.SchemaExport org.hibernate.tool.hbm2ddl.SchemaUpdate org.hibernate.tool.hbm2ddl.SchemaValidator org.hibernate.tool.schema.spi.SchemaManagementTool , or its delegates Schema management tooling changes in JBoss EAP 7.1 Hibernate ORM 5.1.10, included in JBoss EAP 7.1, introduced a strategy for retrieving database tables that improve SchemaMigrator and SchemaValidator performance. This strategy executes a single java.sql.DatabaseMetaData#getTables(String, String, String, String[]) call to determine if each javax.persistence.Entity has a mapped database table. This is the default strategy, and it uses the hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped property setting. This strategy might require hibernate.default_schema and/or hibernate.default_catalog to be provided. To use the old strategy of executing a java.sql.DatabaseMetaData#getTables(String, String, String, String[]) call for each javax.persistence.Entity , use the hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually property setting. 7.8.9. Migrating from Hibernate ORM 5.1 and Hibernate ORM 5.2 to Hibernate ORM 5.3 JBoss EAP 7.4 includes Hibernate ORM 5.3. This section highlights some of the changes needed when migrating from Hibernate ORM 5.1 to Hibernate ORM 5.2 and then to Hibernate ORM 5.3. Hibernate ORM 5.2 features Hibernate ORM 5.2 is built using the Java 8 JDK and requires the Java 8 JRE at runtime. The following is a list of some of the changes made in this release: The hibernate-java8 module was merged into hibernate-core , and the Java 8 date/time datatypes are now natively supported. The hibernate-entitymanager module was merged into hibernate-core . HibernateEntityManager and HibernateEntityManagerFactory are deprecated. The Session , StatelessSession , and SessionFactory class hierarchies were refactored to remove deprecated classes and to better align with the Jakarta Persistence Metamodel API. The SPIs in the org.hibernate.persister and org.hibernate.tuple packages have changed. Any custom classes using those SPIs will need to be reviewed and updated. LimitHandler changes introduced a new hibernate.legacy_limit_handler setting, which is set to false by default, that is designed to allow you to enable the legacy Hibernate 4.3 limit handler behavior. This impacts a limited list of dialects. A new strategy for retrieving database tables was introduced that improves SchemaMigrator and SchemaValidator performance. This release changes how CLOB values for String , character[] , and Character[] attributes that are annotated with @Lob are processed when using PostgreSQL81Dialect and its subclasses. The scope of @TableGenerator and @SequenceGenerator names has changed from global to local. For the complete list of changes implemented in Hibernate 5.2, see Hibernate ORM 5.2 Migration Guide . Hibernate ORM 5.3 features Hibernate ORM 5.3 adds support for the Jakarta Persistence 2.2 specification. This release contains changes to comply with this specification along with other improvements. The following is a list of some of these changes: Changes to positional query parameter handling has resulted in the following changes: Removal of support for JDBC-style parameter declarations in HQL/JPQL queries. Jakarta Persistence positional parameters behave more like named parameters. JDBC-style parameter declarations in native queries use one-based instead of zero-based parameter binding to be consistent with Jakarta Persistence. You can revert back to zero-based binding by setting the hibernate.query.sql.jdbc_style_params_base property to true . To comply with the Jakarta Persistence specification, the sequence value stored by the @TableGenerator stored value is that last generated value. Previously, Hibernate stored the sequence value. You can use the hibernate.id.generator.stored_last_used property to enable the legacy Hibernate behavior. Existing applications that use @TableGenerator and migrate to Hibernate 5.3 must set the hibernate.id.generator.stored_last_used configuration property to false . The getType() method in the org.hibernate.query.QueryParameter class was renamed to getHibernateType() . Hibernate's second-level cache SPI was redesigned to better meet the requirements of the various caching providers. Details can be found in HHH-11356 . Changes for HHH-11356 also required changes in consumers, which impacts the Hibernate Statistics system. Some methods were temporarily added to the org.hibernate.Query class to make it easier to migrate native applications from Hibernate ORM 5.1 to 5.3 and maintain the Hibernate 5.1 pagination behavior. These methods are deprecated, and to be portable with future versions of Hibernate, applications should be updated to use the Jakarta Persistence methods. Support for using Infinispan as a Hibernate 2nd-level cache provider has been moved to the Infinispan project. As a result, the hibernate-infinispan module has been dropped. The API of the org.hibernate.tool.enhance.EnhancementTask Ant task was changed. The addFileset() method was dropped in favor of the setBase() and the setDir() methods. Details can be found in HHH-11795 . A bug introduced in Hibernate 4.3 caused many-to-one associations in embeddable collection elements and composite IDs to be eagerly fetched, even when explicitly mapped as lazy. In Hibernate 5.3.2, this bug was fixed. As a result, these associations are fetched as specified by their mappings. Details can be found in HHH-12687 . Jakarta Persistence and native implementations of Hibernate event listeners were unified in this release. As a result, the JpaIntegrator class is obsolete. Classes that extend org.hibernate.jpa.event.spi.JpaIntegrator must be modified to have to change these classes to implement the org.hibernate.integrator.spi.Integrator interface. Details can be found in HHH-11264 . The SPIs in the org.hibernate.persister package have changed. Any custom classes using those SPIs will need to be reviewed and updated. For the complete list of these and other changes implemented in Hibernate 5.3, see the Hibernate ORM 5.3 Migration Guide . Exception handling changes between Hibernate 5.1 and Hibernate 5.3 In Hibernate 5.2 and 5.3, exception handling for a SessionFactory that is built using Hibernate's native bootstrapping, wraps or converts HibernateException according to the Jakarta Persistence specification. The only exception to this behavior is when the operation is Hibernate-specific, for example Session.save() or Session.saveOrUpdate() . In Hibernate 5.3.3, the hibernate.native_exception_handling_51_compliance property was added. This property indicates whether exception handling for a SessionFactory built using Hibernate's native bootstrapping should behave the same as native exception handling in Hibernate ORM 5.1. When set to true , HibernateException is not wrapped or converted according to the Jakarta Persistence specification. This setting is ignored for a SessionFactory built using Jakarta Persistence bootstrapping. Compatibility transformer JBoss EAP 7.4 includes a compatibility transformer that addresses Hibernate ORM 5.3 API methods that are no longer compatible with Hibernate ORM 5.1. The transformer is a temporary measure to allow applications built using Hibernate ORM 5.1 to exhibit the same behavior with Hibernate 5.3 in JBoss EAP 7.4. This is a temporary solution and you should replace these method calls with the recommended Jakarta Persistence method calls. You can enable the transformer in one of the following ways: You can enable the transformer globally for all applications by setting the Hibernate51CompatibilityTransformer system property to true . You can use the jboss-deployment-structure.xml file to enable the transformer at the application level. <jboss-deployment-structure> <deployment> <transformers> <transformer class="org.jboss.as.hibernate.Hibernate51CompatibilityTransformer"/> </transformers> </deployment> <sub-deployment name="main.war"> <transformers> <transformer class="org.jboss.as.hibernate.Hibernate51CompatibilityTransformer"/> </transformers> </sub-deployment> </jboss-deployment-structure> The following table lists the Hibernate 5.1 methods that are transformed and the Hibernate 5.3 method it is converted to: Hibernate 5.1 Reference or Method Transformed to Hibernate 5.3 Reference or Method org.hibernate.BasicQueryContract.getFlushMode() org.hibernate.BasicQueryContract.getHibernateFlushMode() org.hibernate.Session.getFlushMode() org.hibernate.Session.getHibernateFlushMode() Enum org.hibernate.FlushMode.NEVER (0) Enum org.hibernate.FlushMode.MANUAL (0) org.hibernate.Query.getMaxResults() org.hibernate.Query.getHibernateMaxResults() org.hibernate.Query.setMaxResults(int) org.hibernate.Query.setHibernateMaxResults(int) org.hibernate.Query.getFirstResult(int) org.hibernate.Query.getHibernateFirstResult() org.hibernate.Query.setFirstResult(int) org.hibernate.Query.setHibernateFirstResult(int) 7.9. Hibernate search changes The version of Hibernate Search that is included with JBoss EAP 7 has changed. The release of JBoss EAP included Hibernate Search 4.6.x. JBoss EAP 7 is included with Hibernate Search 5.5.x. Hibernate Search 5.5 is built upon Apache Lucene 5.3.1. If you use any native Lucene APIs, be sure to align with this version. The Hibernate Search 5.5.8.Final wraps and hides the complexity of many of the Lucene API changes made between version 3 and version 5; however, some classes are now deprecated, renamed, or repackaged. This section describes how these changes might impact your application code. In JBoss EAP 8.0, Hibernate Search 5 APIs have been removed and are replaced with Hibernate Search 6 APIs. Additional resources Hibernate search changes 7.9.1. Hibernate Search 6 replaces Hibernate Search 5 APIs Hibernate Search 5 APIs have been removed and are replaced with Hibernate Search 6 APIs in JBoss EAP 8.0. To view a list of the removed features, see Hibernate Search 5 APIs Deprecated in JBoss EAP 7.4 and removed in EAP 8.0 . Note Hibernate Search 6 APIs are backwards-incompatible with Hibernate Search 5 APIs. You will need to migrate your applications to Hibernate Search 6. The latest version of Hibernate Search 6 included in JBoss EAP 8.0 is 6.2. If you are migrating from Hibernate Search 5, you should take into account the migration to version 6.0, 6.1, and 6.2. See the following migrations guides for more information: To migrate your applications from Hibernate Search 5, see the Hibernate Search 6.0 migration guide . To migrate your applications from Hibernate Search 6.0 to 6.1, see the Hibernate Search 6.1 migration guide . To migrate your applications from Hibernate Search 6.1 to 6.2, see the Hibernate Search 6.2 migration guide Note Hibernate Search 6.2 is compatible with Hibernate ORM 6.2. For more information, see the section Hibernate ORM 6 in the Hibernate Search 6.2 Reference documentation. 7.9.2. Hibernate Search 6 supports Elasticsearch JBoss EAP 8.0 also provides support for using an Elasticsearch backend in Hibernate Search 6 to index data into remote Elasticsearch or OpenSearch clusters. To see a list of possible Hibernate Search architectures and backends, see Table 2. Comparison of architectures in the Hibernate Search 6.2 reference documentation. For more information about configuring Hibernate Search 6, see Using Hibernate Search in the WildFly Developer guide. Additional resources Hibernate changes 7.10. Migrate entity beans to Jakarta Persistence Support for Enterprise Java Beans entity beans is optional in Java EE 8 and they are not supported starting with JBoss EAP 7. In releases of JBoss EAP, entity beans were created in application source code by extending the javax.ejb.EntityBean class and implementing the required methods. They were then configured in the ejb-jar.xml file. A CMP entity bean was specified using an <entity> element that contained a <persistence-type> child element with a value of Container . A BMP entity bean was specified using an <entity> element that contained a <persistence-type> child element with a value of Bean . Starting with JBoss EAP 7, you must replace any CMP and BMP entity beans in your code with Jakarta Persistence entities. Jakarta Persistence entities are created using the jakarta.persistence.* classes and are defined in the persistence.xml file. The following is an example of a Jakarta Persistence entity class: import jakarta.persistence.Column; import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.Id; import jakarta.persistence.Table; @Entity // User is a keyword in some SQL dialects! @Table(name = "MyUsers") public class MyUser { @Id @GeneratedValue private Long id; @Column(unique = true) private String username; private String firstName; private String lastName; public Long getId() { return id; } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } The following is an example of a persistence.xml file. <persistence xmlns="https://jakarta.ee/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd" version="3.0"> <persistence-unit name="my-unique-persistence-unit-name"> <properties> // properties... </properties> </persistence-unit> </persistence> For working examples of Jakarta Persistence entities, see the cmt quickstart that is included with JBoss EAP 8.0. 7.11. Jakarta persistence property changes This section describes the Jakarta Persistence property changes introduced in JBoss EAP 7.0 and 7.1. Jakarta Persistence property changes introduced in JBoss EAP 7.0 A new persistence property, jboss.as.jpa.deferdetach , was added to provide compatibility with the persistence behavior in releases of JBoss EAP. The jboss.as.jpa.deferdetach property controls whether the transaction-scoped persistence context used in a non-Jakarta Transactions thread detaches loaded entities after each EntityManager invocation or whether it waits until the persistence context is closed, for example, when the session bean invocation ends. The property value defaults to false , meaning entities are detached or cleared after each EntityManager invocation. This is the correct default behavior as defined in the Jakarta Persistence specification . If the property value is set to true , the entities are not detached until the persistence context is closed. In JBoss EAP 5, persistence behaved as if the jboss.as.jpa.deferdetach property was set to true . To get this same behavior when migrating your application from JBoss EAP 5 to JBoss EAP 7, you must set the jboss.as.jpa.deferdetach property value to true in your persistence.xml as shown in the following example. <?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="EAP5_COMPAT_PU"> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source> <properties> <property name="jboss.as.jpa.deferdetach" value="true" /> </properties> </persistence-unit> </persistence> In JBoss EAP 6, persistence behaved as if the jboss.as.jpa.deferdetach property was set to false . This is the same behavior as seen in JBoss EAP 7, so no changes are necessary when you migrate your application. Jakarta Persistence property changes introduced in JBoss EAP 7.1 In JBoss EAP 7.0, unsynchronized persistence context error checking was not as strict as it should have been in the following areas. A synchronized container-managed persistence context was allowed to use an unsynchronized extended persistence context that was associated with a Jakarta Transactions. Instead, it should have thrown an IllegalStateException to prevent the unsynchronized persistence context from being used. An unsynchronized persistence context specified in a deployment descriptor was treated as synchronized. In addition, PersistenceProperty hints in the @PersistenceContext were mistakenly ignored in JBoss EAP 7.0. These issues were addressed and fixed in JBoss EAP 7.1 and later. Because these updates can result in an unwanted change in application behavior, two new persistence unit properties were introduced in JBoss EAP 7.1 to provide backward compatibility and preserve the behavior. Property Description wildfly.jpa.skipmixedsynctypechecking This property disables the error checking. It should only be used as a temporary measure for backward compatibility in situations where applications worked in JBoss EAP 7.0 and fail in JBoss EAP 7.1 and later. Because this property might be deprecated in a future release, it is recommended that you correct your application code as soon as you are able to do so. wildfly.jpa.allowjoinedunsync This property is an alternative to wildfly.jpa.skipmixedsynctypechecking . It allows the application to treat unsynchronized persistence contexts that are associated with a Jakarta Transactions as if they are synchronized persistence contexts. 7.12. Migrate Jakarta Enterprise Beans client code This section discusses the changes in Jakarta Enterprise Beans client in JBoss EAP 7.0. It also explains how to modify your client code to use the new default remote port and connector in JBoss EAP 7.0. In addition, it describes the required JBoss EJB client changes introduced in JBoss EAP 7.1 and JBoss EAP 7.0. Note Starting with JBoss EAP 7.0, enterprise entity beans are not supported. For more information, see Migrate Entity Beans to Jakarta Persistence . 7.12.1. Jakarta Enterprise Beans client changes in JBoss EAP 7 Starting with JBoss EAP 7, the default remote connector and port have been changed. For details about this change, see Update the Remote URL connector and port . If you used the JBoss Server Migration Tool to migrate your server configuration, the old settings are preserved and you do not need to make the changes detailed here. However, if you use the new JBoss EAP 8.0 default configuration, you must make the following changes. 7.12.1.1. Update the default remote connection port Change the remote connection port value from 4447 to 8080 in the jboss-ejb-client.properties file. The following are examples of a jboss-ejb-client.properties file in the and the current release: Example: JBoss EAP 6 jboss-ejb-client.properties file Example: JBoss EAP 8 jboss-ejb-client.properties file 7.12.1.2. Update the default connector If you use the new JBoss EAP 7 configuration, the default connector has changed from remote to http-remoting . This change impacts clients using libraries from one release of JBoss EAP to connect to a server in a different release. If a client application uses the Jakarta Enterprise Beans client library from JBoss EAP 6 and wants to connect to JBoss EAP 7 server, the server must be configured to expose a remote connector on a port other than 8080 . The client must then connect using that newly configured connector. A client application that uses the Jakarta Enterprise Beans client library from JBoss EAP 7 and wants to connect to JBoss EAP 6 server must be aware that the server instance does not use the http-remoting connector and instead uses a remote connector. This is achieved by defining a new client-side connection property. Example: remote connection property 7.12.2. Migrate remote naming client code If you are running with the new default JBoss EAP 7 configuration, you must modify your client code to use the new default remote port and connector. The following is an example of how remote naming properties were specified in the client code in JBoss EAP 6. The following is an example of how to specify the remote naming properties in the client code in JBoss EAP 7. 7.12.3. Additional JBoss EJB client changes introduced in JBoss EAP 7.1 JBoss EAP 7.0 is included with JBoss Enterprise Java Beans client 2.1.4, JBoss EAP 7.1 and later was included with JBoss Enterprise Java Beans client 4.0.x, which includes a number of changes to the API. Note Starting with JBoss EAP 7, enterprise entity beans are not supported. For information about how to migrate entity beans to Jakarta Persistence, see Migrate Entity Beans to Jakarta Persistence . The org.ejb.client.EJBClientInvocationContext class adds the following new methods: Method Type Description isBlockingCaller() boolean Determine whether this invocation is currently blocking the calling thread. isClientAsync() boolean Determine whether the method is marked client-asynchronous, meaning that invocation must be asynchronous regardless of whether the server-side method is asynchronous. isIdempotent() boolean Determine whether the method is marked idempotent, meaning that the method method be invoked more than one time with no additional effect. setBlockingCaller(boolean) void Establish whether this invocation is currently blocking the calling thread. setLocator(EJBLocator<T>) <T> void Set the locator for the invocation target. The org.ejb.client.EJBLocator class has added the following new methods: Method Type Description asStateful() StatefulEJBLocator<T> Return this locator as a stateful locator, if it is one. asStateless() StatelessEJBLocator<T> Return this locator as a stateless locator, if it is one. isEntity() boolean Determine if this is an entity locator. isHome() boolean Determine if this is a home locator. isStateful() boolean Determine if this is a stateful locator. isStateless() boolean Determine if this is a stateless locator. withNewAffinity(Affinity) abstract EJBLocator<T> Create a copy of this locator, but with the new given affinity. A new org.ejb.client.EJBClientPermission class, which is a subclass of java.security.Permission , is introduced for controlling access to privileged Enterprise Java Beans operations. It provides the following constructors: EJBClientPermission(String name) EJBClientPermission(String name, String actions) It provides the following methods: Method Type Description equals(EJBClientPermission obj) boolean Checks two EJBClientPermission objects for equality. equals(Object obj) boolean Checks two Permission objects for equality. equals(Permission obj) boolean Checks two Permission objects for equality. getActions() String Returns the actions as a string. hashcode() int Returns the hash code value for this Permission object. implies(EJBClientPermission permission) boolean Checks if the specified permission's actions are implied by this EJBClientPermission object's actions. implies(Permission permission) boolean Checks if the specified permission's actions are implied by this Permission object's actions. A new org.ejb.client.EJBMethodLocator class is introduced for locating a specific Enterprise Java Beans method. It provides the following constructor: EJBMethodLocator(String methodName, String... parameterTypeNames) It provides the following methods: Method Type Description equals(EJBMethodLocator other) boolean Determine whether this object is equal to another. equals(Object other) boolean Determine whether this object is equal to another. forMethod(Method method) static EJBMethodLocator Get a method locator for the given reflection method. getMethodName() String Get the method name. getParameterCount() int Get the parameter count. getParameterTypeName(int index) String Get the name of the parameter at the given index. hashCode() int Get the hash code. A new org.jboss.ejb.client.EJBReceiverInvocationContext.ResultProducer.Failed class is introduced for failure cases. It provides the following constructor: Failed(Exception cause) It provides the following methods: Method Type Description discardResult() void Discard the result, indicating that it will not be used. getResult() Object Get the result. A new org.jboss.ejb.client.EJBReceiverInvocationContext.ResultProducer.Immediate class is introduced for immediate results. It provides the following constructor: Failed(Exception cause) It provides the following methods: Method Type Description discardResult() void Discard the result, indicating that it will not be used. getResult() Object Get the result. A new org.jboss.ejb.client.URIAffinity class, which is a subclass of org.jboss.ejb.client.Affinity is introduced for URI affinity specification. It is created using Affinity.forUri(URI) . It provides the following methods: Method Type Description equals(Affinity other) boolean Indicates whether another object is equal to this one. equals(Object other) boolean Indicates whether another object is equal to this one. equals(URIAffinity other) boolean Indicates whether another object is equal to this one. getURI() URI Get the associated URI. hashCode() int Get the hash code. toString() String Returns a string representation of the object. The org.jboss.ejb.client.EJBMetaDataImpl class deprecates the following methods: toAbstractEJBMetaData() EJBMetaDataImpl(AbstractEJBMetaData<?,?>) 7.13. Migrate clients to use the WildFly configuration file Prior to release JBoss EAP 7.1, JBoss EAP client libraries, such as Enterprise Java Beans and naming, used different configuration strategies. JBoss EAP 7.1 introduced the wildfly-config.xml file with the purpose of unifying all client configurations into one single configuration file, in a similar manner to the way the server configuration is handled. For example, prior to JBoss EAP 7.1, you might create a new InitialContext for an Enterprise Java Beans client using a jboss-ejb-client.properties file, or by programmatically setting the properties using a Properties class. Example: jboss-ejb-client.properties properties file In JBoss EAP 7.1 and later, you create a wildfly-config.xml file in the META-INF/ directory of the client archive. This is the equivalent configuration using a wildfly-config.xml file. Example: Equivalent configuration using the wildfly-config.xml file <configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="ejb"/> </authentication-rules> <authentication-configurations> <configuration name="ejb"> <set-user-name name="quickuser"/> <credentials> <clear-password password="quick-123"/> </credentials> </configuration> </authentication-configurations> </authentication-client> <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.2"> <connections> <connection uri="remote+http://127.0.0.1:8080" /> </connections> </jboss-ejb-client> </configuration> Additional resources Configure Client Authentication with Elytron Client . Client Configuration Using the wildfly-config.xml File . 7.14. Migrate deployment plan configurations The Java EE Application Deployment specification (JSR-88) was intended to define a standard contract to enable tools from multiple providers to configure and deploy applications on any Java EE platform product. The contract required Java EE Product Providers to implement the DeploymentManager and other javax.enterprise.deploy.spi interfaces to be accessed by the Tool Providers. In case of JBoss EAP 6, a deployment plan is identified by an XML descriptor named deployment-plan.xml that is bundled in a archive or JAR archive. This specification saw very little adoption because most application server products provide their own more "feature rich" deployment solutions. For this reason, JSR-88 support was dropped from Java EE 7 and, in turn, from JBoss EAP 7. If you used JSR-88 to deploy your application, you must now use another method to deploy the application. The JBoss EAP management CLI deploy command provides a standard way to deploy archives to standalone servers or to server groups in a managed domain. For more information about the management CLI, see the Management CLI Guide . 7.15. Migrate custom application valves You must manually migrate custom valves or any valves that are defined in the jboss-web.xml XML file. This includes valves created by extending the org.apache.catalina.valves.ValveBase class and configured in the <valve> element of the jboss-web.xml descriptor file. Migrate Valves Configured in Deployments In JBoss EAP 6, you could define custom valves at the application level by configuring them in the jboss-web.xml web application descriptor file. Since JBoss EAP 7, it is possible to do this with Undertow handlers as well. The following is an example of a valve configured in the jboss-web.xml file in JBoss EAP 6. <jboss-web> <valve> <class-name>org.jboss.examples.MyValve</class-name> <param> <param-name>myParam</param-name> <param-value>foobar</param-value> </param> </valve> </jboss-web> For more information about how to create and configure custom handlers in JBoss EAP, see Creating Custom Handlers in the JBoss EAP 7.4 Development Guide . Migrate Custom Authenticator Valves For information about how to migrate authenticator valves, see Migrate authenticator valves . 7.16. Security application changes The replacement of JBoss Web with Undertow requires changes to security configuration since JBoss EAP 7. Starting with JBoss EAP 8.0, you must use Elytron as the legacy security since PicketBox is no longer available. 7.16.1. Migrate authenticator valves If you created a custom authenticator valve that extended AuthenticatorBase in JBoss EAP 6.4, you must manually replace it with a custom HTTP authentication implementation in JBoss EAP 7. The HTTP authentication mechanism is created in the elytron subsystem and then registered with the undertow subsystem. For information about how to implement a custom HTTP authentication mechanism, see Developing a Custom HTTP Mechanism in the JBoss EAP 7.4 Development Guide . 7.16.2. PicketLink removal PicketLink has been removed from JBoss EAP 8.0. PicketLink SP Use Keycloak SAML adapter instead of the PicketLink service provider. To migrate from PicketLink by configuring the Keycloak SAML adapter, perform the following tasks: Install Keycloak SAML client to JBoss EAP 8.0. For more information, see Installing JBoss EAP 8.0 using the jboss-eap-installation-manager Keycloak SAML adapter feature pack for securing applications using SAML Configure a Keycloak SAML instead of PicketLink IdP if needed. To secure the SP application using Keycloak SAML, a SAML client needs to be created. For more information on creating an Keycloak SAML client, see Creating a SAML client in the JBoss EAP 7.5 Server Administration Guide . Update the applications to use the Keycloak SAML adapter. For more information on updating the applications, see Securing web applications using SAML . PicketLink IDP PicketLink IDP is not available since JBoss EAP 8.0 and you can configure Red Hat build of Keycloak instead. For more information, see Configuring Red Hat build of Keycloak . PicketLink STS In releases, you could configure PicketLink STS as an alternative to the Apache CXF Security Token Service implementation. PicketLink STS configuration involved a legacy security domain. Any references to legacy security domains and PicketLink in the STS application needs to be removed, so you must configure Apache CXF STS instead. For more information on how to configure Apache CXF STS, see Security Token Service (STS) in the JBoss EAP 7.4 Developing Web Services Applications . 7.16.3. Vault removal Vaults has been removed from JBoss EAP 8.0. If your applications use legacy vault expressions, you must migrate and use Elytron encrypted expressions. Check for instances of USD{VAULT:: in your deployment files, which could be in annotations or deployment descriptors, and replace them with the corresponding encrypted expressions. Additional resources Encrypted expressions in Elytron 7.16.4. OIDC client migration The Keycloak OIDC client adapter is not supported in JBoss EAP 8.0 and is replaced by the native Elytron OIDC client, providing similar functionality and configuration. To migrate from the Keycloak OIDC client adapter to the native Elytron OIDC client, follow these steps: Check for <auth-method>KEYCLOAK</auth-method> in the web.xml file of the application and replace it with <auth-method>OIDC</auth-method> in the web.xml file of the deployment. Check for the presence of WEB-INF/keycloak.json and rename it to WEB-INF/oidc.json . Additional resources OpenID Connect configuration in JBoss EAP Migrate keycloak subsystem 7.16.5. Custom login modules migration In JBoss EAP 8.0, the legacy security subsystem has been removed. To continue using your custom login modules with the elytron subsystem, use the new Java Authentication and Authorization Service (JAAS) security realm and jaas-realm . Additional resources JAAS realm in the elytron subsystem 7.16.6. Other security application changes There are a few noticeable differences between JBoss EAP 7.2 or higher and earlier versions: The NegotiationAuthenticator valve is not required in the jboss-web.xml , but there still must be <security-constraint> and <login-config> elements defined in the web.xml . These are used to decide which resources are secured. The auth-method element in the <login-config> element is now a comma-separated list. The exact value SPNEGO must be there and should appear first in that list. In cases where FORM authentication is desired as a fallback, the exact value would be SPNEGO,FORM . The jboss-deployment-structure.xml file is not required. 7.17. JBoss Logging Changes Starting with JBoss EAP 7, if your application uses JBoss Logging, be aware that the annotations in the org.jboss.logging package are deprecated. They have been moved to the org.jboss.logging.annotations package, so you must update your source code to import the new package. The annotations have also moved to a separate Maven groupId:artifactId:version (GAV) ID so you need to add a new project dependency for org.jboss.logging:jboss-logging-annotations in your project pom.xml file. Note Only the logging annotations have moved. The org.jboss.logging.BasicLogger and org.jboss.logging.Logger still exist in the org.jboss.logging package. The following table lists the deprecated annotation classes and corresponding replacements. Table 7.1. Deprecated Logging Annotation Replacements Deprecated Class Replacement Class org.jboss.logging.Cause org.jboss.logging.annotations.Cause org.jboss.logging.Field org.jboss.logging.annotations.Field org.jboss.logging.FormatWith org.jboss.logging.annotations.FormatWith org.jboss.logging.LoggingClass org.jboss.logging.annotations.LoggingClass org.jboss.logging.LogMessage org.jboss.logging.annotations.LogMessage org.jboss.logging.Message org.jboss.logging.annotations.Message org.jboss.logging.MessageBundle org.jboss.logging.annotations.MessageBundle org.jboss.logging.MessageLogger org.jboss.logging.annotations.MessageLogger org.jboss.logging.Param org.jboss.logging.annotations.Param org.jboss.logging.Property org.jboss.logging.annotations.Property 7.18. Jakarta Faces code changes This section describes the impact of the Jakarta Faces code changes in migrating your application to JBoss EAP. Dropped support for Jakarta Server Faces prior to 4.0 Note Jakarta Server Faces is the new name for JavaServer Faces. With JBoss EAP 6.4, you could continue to use Jakarta Server Faces 1.2 with your application deployment by creating a jboss-deployment-structure.xml file. JBoss EAP 7.4 includes Jakarta Server Faces 2.3 and no longer supports the Jakarta Server Faces 1.2 API. If your application uses Jakarta Server Faces 1.2, you must rewrite it to use Jakarta Server Faces 2.3. JBoss EAP 8.0 no longer supports any version of JSF prior to 4.0. 7.19. Integrate MyFaces for alternative faces You can simplify the installation of an alternative Jakarta Faces implementation, MyFaces , as an alternative to the default Mojarra Jakarta Faces implementation within the JBoss EAP by introducing the Galleon feature pack, eap-myfaces-feature-pack . You can use this feature pack to provision a different Jakarta Faces implementation within JBoss EAP. You can use the eap-myfaces-feature-pack to select the MyFaces version by using the MYFACES_VERSION environment variable. This feature pack introduces a single layer named MyFaces , providing the option to install and select MyFaces as an alternative. For more information, see How to configure the Multi-JSF feature in EAP 8 . Note Compatibility with JBoss EAP 8.0 is limited to versions 4.x and above. 7.20. Module class loading changes In JBoss EAP 7, the class loading behavior has changed in cases where multiple modules contain the same classes or packages. Assume there are two modules, MODULE_A and MODULE_B , that depend upon each other and contain some of the same packages. In JBoss EAP 6, the classes or packages that were loaded from the dependencies took precedence over those specified in the resource-root of the module.xml file. This meant MODULE_A saw the packages for MODULE_B and MODULE_B saw the packages for MODULE_A . This behavior was confusing and could cause conflicts. This behavior has changed in JBoss EAP 7. Now the classes or packages specified by the resource-root in the module.xml file take precedence over those specified by the dependency. This means MODULE_A sees the packages for MODULE_A and MODULE_B sees the packages for MODULE_B . This prevents conflicts and provides a more appropriate behavior. If you have defined custom modules that include resource-root libraries or packages that contain classes that are duplicated in their module dependencies, you might see ClassCastException , LinkageError , class loading errors, or other changes in behavior when you migrate to JBoss EAP 7. To resolve these issues, you must configure your module.xml file to ensure only one version of a class is used. This can be accomplished by using either of the following approaches. You can avoid specifying a resource-root that duplicates classes in the module dependency. You can use the include and exclude sub-elements of the imports and exports elements to control class loading in the module.xml file. The following is an export element that excludes classes is in the specified package. <exports> <exclude path="com/mycompany/duplicateclassespath/"/> </exports> If you prefer to preserve your existing behavior, you must filter the dependency packages from the dependent resource-root in the module.xml file using the filter element. This allows you to retain the existing behavior without the odd looping that you would see under JBoss EAP 6. The following is an example of a root-resource that filters classes in a specified package. <resource-root path="mycompany.jar"> <filter> <exclude path="com/mycompany/duplicateclassespath"/> </filter> </resource-root> For more information about modules and class loading, see Class Loading and Modules in the JBoss EAP 7.4 Development Guide . 7.21. Application Clustering Changes This section provides an overview of the clustering changes required for migrating your application from JBoss EAP 6 to JBoss EAP 8. In addition, this section describes how clustering changes might impact the migration of your applications to JBoss EAP 8.0. 7.21.1. Overview of new clustering features The following list describes some of the new clustering features to be aware of when migrating your application from JBoss EAP 6 to JBoss EAP 8.0. JBoss EAP 7 introduces a new public API for building singleton services that significantly simplifies the process. For information on singleton services, see HA Singleton Service in the JBoss EAP 7.4 Development Guide A singleton deployment can be configured to deploy and start on only a single node in the cluster at a time. For more information, see HA Singleton Deployments in the JBoss EAP 7.4 Development Guide . You can now define clustered singleton MDBs. For more information, see Clustered Singleton MDBs in the JBoss EAP 7.4 Developing Jakarta Enterprise Beans Applications . JBoss EAP 8.0 includes the Undertow mod_cluster implementation. This offers a pure Java load balancing solution that does not require an httpd web server. For more information, see Configuring JBoss EAP as a Front-end Load Balancer in the JBoss EAP 7.4 Configuration Guide . 7.21.2. Web Session Clustering Changes JBoss EAP 7 introduces a new web session clustering implementation. It replaces the implementation, which was tightly coupled to the legacy JBoss Web subsystem source code. The new web session clustering implementation impacts how the application is configured in the jboss-web.xml JBoss EAP proprietary web application XML descriptor file. The following are the only clustering configuration elements that remain in this file. <jboss-web> ... <max-active-sessions>...</max-active-sessions> ... <replication-config> <replication-granularity>...</replication-granularity> <cache-name>...</cache-name> </replication-config> ... </jboss-web> The distributable-web subsystem deprecates the <replication-config> element of jboss-web.xml . It enhances the usage of <replication-config> by generating an ad hoc distributable web session profile. You can override the default distributable session management behavior by referencing a session management profile by name or by providing a deployment-specific session management configuration. For more information, see Overriding the default distributable session management behavior . The following table describes how to achieve similar behavior for elements in the jboss-web.xml file that are now obsolete. Configuration Element Description of Change <max-active-sessions/> Previously, the session creation would fail if it caused the number of active sessions to exceed the value specified by <max-active-sessions/> . In the new implementation, <max-active-sessions/> is used to enable session passivation. If session creation will cause the number of active sessions to exceed the <max-active-sessions/> , then the oldest session known to the session manager will passivate to make room for the new session. <passivation-config/> Starting with JBoss EAP 7, this configuration element and its sub-elements are no longer used. <use-session-passivation/> Previously, passivation was enabled using this attribute. In the new implementation, passivation is enabled by specifying a non-negative value for <max-active-sessions/> . <passivation-min-idle-time/> Previously, sessions needed to be active for a minimum amount of time before becoming a candidate for passivation. This could cause session creation to fail, even when passivation was enabled. The new implementation does not support this logic and thus avoids this Denial of Service (DoS) vulnerability. <passivation-max-idle-time/> Previously, a session would be passivated after it was idle for a specific amount of time. The new implementation only supports lazy passivation. It does not support eager passivation. Sessions are only passivated when necessary to comply with <max-active-sessions/> . <replication-config/> The distributable-web subsystem deprecates this element. For more information, see The distributable-web subsystem for Distributable Web Session Configurations in the JBoss EAP 7.4 Development Guide and Overriding the default distributable session management behavior . <replication-trigger/> Previously, this element was used to determine when session replication was triggered. The new implementation replaces this configuration option with a single, robust strategy. For more information, see Immutable Session Attributes in the JBoss EAP 7.4 Development Guide . <use-jk/> Previously, the instance-id of the node handling a given request was appended to the jsessionid , for use by load balancers such as mod_jk, mod_proxy_balancer, mod_cluster, depending on the value specified for <use-jk/> . In the new implementation, the instance-id , if defined, is always appended to the jsessionid . <max-unreplicated-interval/> Previously, this configuration option was intended as an optimization to prevent the replication of a session's timestamp if no session attribute was changed. While this sounds nice, in practice it does not prevent any RPCs, since session access requires cache transaction RPCs regardless of whether any session attributes changed. In the new implementation, the timestamp of a session is replicated on every request. This prevents stale session metadata following a failover. <snapshot-mode/> Previously, one could configure <snapshot-mode/> as INSTANT or INTERVAL . Infinispan's asynchronous replication makes this configuration option obsolete. <snapshot-interval/> This was only relevant for <snapshot-mode>INTERVAL</snapshot-mode> . Since <snapshot-mode/> is obsolete, this option is now obsolete as well. <session-notification-policy/> Previously, the value specified by this attribute defined a policy for triggering session events. In the new implementation, this behavior is specification-driven and not configurable. This new implementation also supports write-through cache stores as well as passivation-only cache stores. Typically, a write-through cache store is used in conjunction with an invalidation cache. The web session clustering implementation in JBoss EAP 6 did not operate correctly when used with an invalidation cache. 7.21.3. Overriding the default distributable session management behavior You can override the default distributable session management behavior in one of the following ways: Referencing a session management profile by name Providing a deployment-specific session management configuration Referencing an existing session management profile To use an existing distributed session management profile, include a distributable-web.xml deployment descriptor located in the application's /WEB-INF directory. For example: /WEB-INF/distributable-web.xml <?xml version="1.0" encoding="UTF-8"?> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <session-management name="foo"/> </distributable-web> Alternatively, define the target distributed session management profile within an existing jboss-all.xml deployment descriptor: /META-INF/jboss-all.xml <?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <session-management name="foo"/> </distributable-web> </jboss> Using a Deployment-specific Session Management Profile If only a single web application uses the custom session management configuration, you can define the configuration within the deployment descriptor itself. Ad hoc configuration looks identical to the configuration used by the distributable-web subsystem. Define the custom session management configuration within the deployment descriptor. For example: /WEB-INF/distributable-web.xml <?xml version="1.0" encoding="UTF-8"?> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <infinispan-session-management cache-container="foo" cache="bar" granularity="SESSION"> <primary-owner-affinity/> </infinispan-session-management> </distributable-web> Alternatively, define the session management configuration within an existing jboss-all.xml deployment descriptor: /META-INF/jboss-all.xml <?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <infinispan-session-management cache-container="foo" cache="bar" granularity="ATTRIBUTE"> <local-affinity/> </infinispan-session-management> </distributable-web> </jboss> 7.21.4. Stateful session EJB clustering changes In JBoss EAP 6, you were required to enabled the clustering behavior for stateful session beans (SFSBs) in one of the following ways: You could add the org.jboss.ejb3.annotation.Clustered annotation in the session bean. @Stateful @Clustered public class MyBean implements MySessionInt { public void myMethod() { // } } You could add the <clustered> element to the jboss-ejb3.xml file. <c:clustering> <ejb-name>DDBasedClusteredSFSB</ejb-name> <c:clustered>true</c:clustered> </c:clustering> Starting with JBoss EAP 7, you no longer need to enable the clustering behavior. By default, if the server is started using an HA profile, the state of SFSBs will be replicated automatically. You can disable this default behavior in one of the following ways: You can disable the default behavior for a single stateful session bean by using @Stateful(passivationCapable=false) , which is new to the Enterprise Java Beans 3.2 specification. You can disable this behavior globally in the configuration of the ejb3 subsystem in the server configuration. Note If the @Clustered annotation is not removed from the application, it is simply ignored and does not affect the deployment of the application. 7.21.5. Clustering services changes In JBoss EAP 6, the APIs for clustering services were in private modules and were not supported. JBoss EAP 7 introduces a public clustering services API for use by applications. The new services are designed to be lightweight, easily injectable, and require no external dependencies. The new org.wildfly.clustering.group.Group interface provides access to the current cluster status and allows listening for cluster membership changes. The new org.wildfly.clustering.dispatcher.CommandDispatcher interface allows running code in the cluster, on all or a selected subset of nodes. These services replace similar APIs that were available in releases, namely HAPartition from JBoss EAP 5 and GroupCommunicationService , GroupMembershipNotifier , and GroupRpcDispatcher in JBoss EAP 6. For more information, see Public API for Clustering Services in the JBoss EAP 7.4 Development Guide . 7.21.6. Migrate Clustering HA Singleton In JBoss EAP 6, there was no public API available for the cluster-wide HA singleton service. If you used the private org.jboss.as.clustering.singleton.* classes, you must change your code to use the new public org.wildfly.clustering.singleton.* packages when you migrate your application to JBoss EAP 8. For more information about HA singleton services, see HA Singleton Service in the JBoss EAP 7.4 Development Guide . For information about HA singleton deployments, see HA Singleton Deployments in the JBoss EAP 7.4 Development Guide . 7.22. ContextService customization by using context types As part of Jakarta EE Concurrency 3.0, you can customize the ContextService property by using context types. The Transaction context is one such type. The Transaction context replaces the use of the use-transaction-setup-provider resource-definition attribute. When the use-transaction-setup-provider attribute is set to true , the transaction context is cleared and when this attribute is set to false , the transaction context is unchanged. Red Hat no longer supports vendor-specific configurations and therefore, such resource-definition attributes have been deprecated. In JBoss EAP 7, the default configurations defined the use-transaction-setup-provider attribute as false , which means that the transaction context was unchanged when a contextual task was run on a thread. By default, in JBoss EAP 8, the default ContextService property is aligned with the Jakarta EE Concurrency 3.0 specification, and clears the transaction context before a contextual task is executed. To use a different ContextService , you must define it on the deployment by using the ContextServiceDefinition annotation or by specifying it in XML. 7.23. Removal of deprecated InitialContext class The org.jboss.naming.remote.client.InitialContextFactory class is removed in JBoss EAP 8. In JBoss EAP 7, the org.jboss.naming.remote.client.InitialContextFactory class had been deprecated and replaced with the org.wildfly.naming.client.WildFlyInitialContextFactory class. You must migrate your source code or configuration files to reflect this change. Naming configuration changes: If a user application is using system or environment properties, then java.naming.factory.initial property must be migrated from java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory to java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory . If a user application is using WSDL contracts that contain <soapjms:jndiInitialContextFactory> , then their values must be migrated from <soapjms:jndiInitialContextFactory>org.jboss.naming.remote.client.InitialContextFactory<soapjms:jndiInitialContextFactory> to <soapjms:jndiInitialContextFactory>org.wildfly.naming.client.WildFlyInitialContextFactory<soapjms:jndiInitialContextFactory> . If a user application is using Java code to configure remote naming, then it must be updated from Properties env = new Properties();env.put(Context.INITIAL_CONTEXT_FACTORY, org.jboss.naming.remote.client.InitialContextFactory.class.getName()); to env.put(Context.INITIAL_CONTEXT_FACTORY, org.wildfly.naming.client.WildFlyInitialContextFactory.class.getName()); . The methods listed below, from the org.wildfly.naming.client.ProviderEnvironment class, have been deprecated in JBoss EAP 7 and are now removed in JBoss EAP 8 as part of Red Hat's commitment to replacing problematic language in our code, documentation, and web properties. For more details, see our CTO Chris Wright's message . Any code containing a removed method must be refactored using the corresponding replacement: getBlackList() replaced by getBlockList() updateBlacklist(URI) replaced by updateBlockList(URI) dropFromBlacklist(URI) replaced by dropFromBlocklist(URI) 7.24. Resource Adapters A Jakarta Connectors Resource Adapter lets your applications communicate with any messaging provider. It configures how Jakarta EE components such as MDBs and other Jakarta Enterprise Beans, and even Servlets, can send or receive messages. 7.24.1. Deploying the IBM MQ Resource Adapter IBM MQ is the Messaging Oriented Middleware (MOM) product offering from IBM that allows applications on distributed systems to communicate with each other. This is accomplished through the use of messages and message queues. IBM MQ is responsible for delivering messages to the message queues and for transferring data to other queue managers using message channels. For more information about IBM MQ, see IBM MQ on the IBM products website. Summary IBM MQ can be configured as an external Java Message Service provider for JBoss EAP 8.0. This section covers the steps to deploy and configure the IBM MQ resource adapter in JBoss EAP. This deployment and configuration can be accomplished by using the management CLI tool or the web-based management console. See JBoss EAP supported configurations for the most current information about the supported configurations of IBM MQ. Note You must restart your system after configuring your IBM MQ resource adapter for the configuration changes to take effect. JBoss EAP 8.0 is a Jakarta EE 10 implementation, so the packages used for all EE APIs have changed from javax to jakarta, which requires a Jakarta EE 10 compliant resource adapter. If you were using the IBM MQ Resource adapter in JBoss EAP 7.x or earlier, you must use wmq.jakarta.jmsra.rar , the IBM MQ Resource Adapter that uses this jakarta namespace. Remove and undeploy the resource adapter configuration for wmq.jmsra.rar and use wmq.jakarta.jmsra.rar Deploy wmq.jakarta.jmsra.rar and configure as per the steps provided in this section. Prerequisites Before you get started, you must verify the version of the IBM MQ resource adapter and understand its configuration properties. The IBM MQ resource adapter is supplied as a Resource Archive (RAR) file called wmq.jakarta.jmsra.rar . You can obtain the wmq.jakarta.jmsra.rar file from /opt/mqm/java/lib/jca/wmq.jakarta.jmsra.rar . See JBoss EAP supported configurations for information about the specific versions that are supported for each release of JBoss EAP. You must know the following IBM MQ configuration values. Refer to the IBM MQ product documentation for details about these values. MQ_QUEUE_MANAGER : The name of the IBM MQ queue manager MQ_HOST_NAME : The host name used to connect to the IBM MQ queue manager MQ_CHANNEL_NAME : The server channel used to connect to the IBM MQ queue manager MQ_QUEUE_NAME : The name of the destination queue MQ_TOPIC_NAME : The name of the destination topic MQ_PORT : The port used to connect to the IBM MQ queue manager MQ_CLIENT : The transport type For outbound connections, you must also be familiar with the following configuration value: MQ_CONNECTIONFACTORY_NAME : The name of the connection factory instance that will provide the connection to the remote system Procedure The following are default configurations provided by IBM and are subject to change. Refer to the IBM MQ documentation for more information. First, deploy the resource adapter manually by copying the wmq.jakarta.jmsra.rar file to the EAP_HOME /standalone/deployments/ directory. , use the management CLI to add the resource adapter and configure it. Note that the transaction-support element was set to XATransaction . When using transactions, be sure to supply the security domain of the XA recovery datasource, as in the example below. For more information about XA Recovery, see Configuring XA Recovery in the JBoss EAP 7.4 Configuration Guide . For non-transactional deployments, change the value of transaction-support to NoTransaction . Now that the resource adapter is created, you can add the necessary configuration elements to it. Add an admin-object for queues and configure its properties. Add an admin-object for topics and configure its properties. Add a connection definition for a managed connection factory and configure its properties. If you want to change the default provider for the EJB3 messaging system in JBoss EAP from JBoss EAP 8.0 messaging to IBM MQ, use the management CLI to modify the ejb3 subsystem as follows: Configure the @ActivationConfigProperty and @ResourceAdapter annotations in the MDB code as follows: @MessageDriven(name="IbmMqMdb", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType",propertyValue = "jakarta.jms.Queue"), @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"), @ActivationConfigProperty(propertyName = "hostName", propertyValue = " MQ_HOST_NAME "), @ActivationConfigProperty(propertyName = "port", propertyValue = " MQ_PORT "), @ActivationConfigProperty(propertyName = "channel", propertyValue = " MQ_CHANNEL_NAME "), @ActivationConfigProperty(propertyName = "queueManager", propertyValue = " MQ_QUEUE_MANAGER "), @ActivationConfigProperty(propertyName = "destination", propertyValue = " MQ_QUEUE_NAME "), @ActivationConfigProperty(propertyName = "transportType", propertyValue = " MQ_CLIENT ") }) @ResourceAdapter(value = "wmq.jakarta.jmsra-VERSION.rar") @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public class IbmMqMdb implements MessageListener { } Be sure to replace the VERSION in the @ResourceAdapter value with the actual version in the name of the RAR. Activate your resource adapter: 7.24.1.1. Limitations and known issues of IBM MQ resource adapters The following table lists known issues with the IBM MQ resource adapters. A checkmark ( ✔ ) in the version column indicates the issue is a problem for that version of the resource adapter. Table 7.2. Known Issues with the IBM MQ Resource Adapters JIRA Description of Issue IBM MQ 9 JBEAP-503 The IBM MQ resource adapter returns different String values for the Queue.toString() and QueueBrowser.getQueue().toString() methods. Queue is instance of the com.ibm.mq.connector.outbound.MQQueueProxy class, which is different from the com.ibm.mq.jms.MQQueue class that is returned by the QueueBrowser.htmlQueueBrowser.getQueue() method. These classes contain different implementations of the toString() method. Be aware that you cannot rely on these toString() methods to return the same value. ✔ JBEAP-511 , JBEAP-550 , JBEAP-3686 The following restrictions apply to message property names for IBM MQ. In the activation-config section of the deployment descriptor, you must not configure the destinationName property using special characters such as _ , & , or | . Use of these characters causes the MDB deployment to fail with a com.ibm.msg.client.jms.DetailedInvalidDestinationException exception. In the activation-config section of the deployment descriptor, you must not configure the destinationName property using the java:/ prefix. Use of this prefix causes the MDB deployment to fail with a com.ibm.msg.client.jms.DetailedInvalidDestinationException exception. A property must not begin with "JMS" or "usr.JMS" as they are reserved for use by IBM MQ JMS classes. Exceptions are noted on the IBM Knowledge Center website. See Property name restrictions for IBM MQ, Version 9.0 on the IBM Knowledge Center website for the complete list of message property name restrictions. ✔ JBEAP-549 When specifying the destination property name value for an MDB using the @ActivationConfigProperty annotation, you must use all upper case letters. For example: @ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE") ✔ JBEAP-624 If the IBM MQ resource adapter is used to create a connection factory in a Jakarta EE deployment using the @JMSConnectionFactoryDefinition annotation, you must specify the resourceAdapter property. Otherwise, the deployment will fail. @JMSConnectionFactoryDefinition( name = "java:/jms/WMQConnectionFactory", interfaceName = "javax.jms.ConnectionFactory", resourceAdapter = "wmq.jmsra", properties = { "channel=<channel>", "hostName=<hostname_wmq_broker>", "transportType=<transport_type>", "queueManager=<queue_manager>" } ) ✔ JBEAP-2339 The IBM MQ resource adapter is able to read messages from queues and topics even before the connection has started. This means a consumer can consume messages before the connection is started. To avoid hitting this issue, use connection factories created by the remote IBM MQ broker using the external-context and not connection factories created by IBM MQ resource adapter. ✔ JBEAP-3685 Once <transaction-support>XATransaction</transaction-support> is set, a JMSContext is always JMSContext.SESSION_TRANSACTED , whether it was created using injection or manually. In the following code example, the @JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE) is ignored and the JMSContext remains at JMSContext.SESSION_TRANSACTED . @Inject @JMSConnectionFactory("jms/CF") @JMSPasswordCredential(userName="myusername", password="mypassword") @JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE) transient JMSContext context3; ✔ JBEAP-14633 According to the JMS specification, the QueueSession interface cannot be used to create objects specific to the publish/subscribe domain and certain methods that inherit from Session should throw an javax.jms.IllegalStateException . One such method is such QueueSession.createTemporaryTopic() . Instead of throwing an javax.jms.IllegalStateException , the IBM MQ resource adapter throws a java.lang.NullPointerException . ✔ JBEAP-14634 The MQTopicProxy.getTopicName() returns different topic name than was set by the IBM MQ broker. For example, if the topic name was set to topic://MYTOPIC?XMSC_WMQ_BROKER_PUBQ_QMGR=QM , the MQTopicProxy returns topic://MYTOPIC . ✔ JBEAP-14636 The default autoStart setting for the JMSContext is false , meaning the underlying connection used by the JMSContext is not started automatically when a consumer is created. This setting should default to true . ✔ JBEAP-14640 The IBM MQ resource adapter throws DetailedJMSException instead of a JMSSecurityException when invalid credentials are used and logs the following error to the server console. The following is an example of code that can cause this issue. QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword"); ✔ JBEAP-14642 Due to an invalid class cast conversion by the resource adapter in the MQMessageProducer.send(Destination destination, Message message) and MQMessageProducer.send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener) methods, the IBM MQ resource adapter throws a JMSException and logs the following error message to the server console. This is because the JNDI name used in the queue or topic lookup is com.ibm.mq.connector.outbound.MQQueueProxy/MQTopicProxy . ✔ JBEAP-14643 The setDeliveryDelay(expDeliveryDelay) method on the JMSProducer interface does not change the setting. After calling this method, it remains at the default setting of 0 . ✔ JBEAP-14670 If work is done on a QueueSession that was created prior to a UserTransaction.begin() , that work is not considered part of the transaction. This means that any message sent to the queue using this session is not committed by a UserTransaction.commit() , and after a UserTransaction.rollback() , the message remains on the queue. ✔ JBEAP-14675 If you close a connection and then immediately create a JMSContext with the same clientID , the IBM MQ resource adapter intermittently logs the following error to the server console. This issue does not occur when there is a delay in creating the new JMSContext after the connection with the same clientID is closed. ✔ JBEAP-15535 If a stateful session bean tries to send a message to a topic while in a container managed transaction (CMT), the message send fails with the following message. The stack trace shows it to be caused by the following exception. JBEAP-25561 When a message is sent to the destination with the JMSReplyTo header set, it is modified after reaching the IBM MQ 9 broker. As a result, the reply message of the response is directed to the destination defined in the modified JMS_REPLY header. For example, if the JMSReplyTo header is set to queue with the name queue:///MYQUEUE using the header message.setJMSReplyTo(queue); and sent to a IBM MQ 9.3 broker with queue manager named QM , then its name is changed to queue://QM/MYQUEUE . ✔ 7.24.2. Removal of Apache Log4j version 1 APIs Starting with JBoss EAP 8, support for Apache Log4j version 1 APIs has been stopped. Any application that is not packaging log4j.jar and log4j configuration must be updated. Impact: Log messages will no longer be routed based on the logging subsystem. If an application is not packaging log4j.jar and any of the following statements are true, then migration changes are required: If you use log4j in your deployment and do not include a log4j configuration file, then you must either migrate to a new logging facade or add a log4j configuration to your deployment. If you use a log4j.xml , log4j.properties , or jboss-log4j.xml file in your deployment and are not packaging the log4j.jar in your application. If it is a jboss-log4j.xml file, then you must rename the file to log4j.xml . If you use log4j v1 appenders in the JBoss EAP Logging subsystem in a custom-handler, it will be no longer supported. If an application classes import classes such as org.apache.log4j.Logger . If the application includes a jboss-deployment-structure.xml or has Dependencies: specified in the MANIFEST.MF declaring a module dependency on org.jboss.log4j.logmanager , these dependencies will need to be removed. Migration: Update the application classes to use Apache Log4jv2 classes or use one of the other Logging APIs provided by JBoss EAP 8. Change the org.apache.log4j.Logger (log4j v1) class to org.apache.logging.log4j.Logger (log4j v2) . If an application packages log4j.properties , log4j.xml , or jboss-log4j.xml , you must:: Configure the logging in the JBoss EAP configuration. Configure logging.properties in an application as the log4jv2 configuration files are not supported in an application. OR Package the Apache Log4j version 1 JAR in the application instead of depending on JBoss EAP 8 for the Logging APIs. You can also exclude the JBoss Logging APIs from the application by the jboss-deployment-structure.xml exclude-subsystems on the logging subsystem. Additional Details: Disabling implicit logging dependencies for a specific deployment In an application's jboss-deployment-structure.xml , configure exclude-subsystems to exclude the logging subsystem such as: <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <exclude-subsystems> <subsystem name="logging"/> </exclude-subsystems> </deployment> </jboss-deployment-structure> If the application is an EAR file and has a sub-deployment named example.war , the jboss-deployment-structure.xml file is located in the EAR file location / META-INF/jboss-deployment-structure.xml and the logging subsystem will be excluded by declaring it in the sub-deployment such as: <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <sub-deployment name="example.war"> <exclude-subsystems> <subsystem name="logging"/> </exclude-subsystems> </sub-deployment> </jboss-deployment-structure> Disabling implicit logging dependencies for all deployments To make logging APIs unavailable to deployments by default, set add-logging-api-dependencies to false by using the following CLI command: /subsystem=logging:write-attribute(name="add-logging-api-dependencies", value="false") To set the JBoss Module and Logging API as a dependency, modify the jboss-deployment-structure.xml or MANIFEST.MF configuration files: <subsystem xmlns="urn:jboss:domain:logging:8.0"> <add-logging-api-dependencies value="false"/> ... </subsystem> Note If an application packages Apache Log4j v1 JARs and log4j configuration in an application: * Application logging is no longer managed by EAP, it is application managed. * An application should not attempt to write to the server.log as unexpected results can occur because logging frameworks are expected to be writing to specific log files. For more information, see Apache Log4j version 1 is no longer provided in JBoss EAP 8.0 .

Commands:
<webservices xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1"> <webservice-description> <webservice-description-name>HelloService</webservice-description-name> <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file> <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file> <port-component> <port-component-name>Hello</port-component-name> <wsdl-port>HelloPort</wsdl-port> <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface> <service-impl-bean> <servlet-link>HelloWorldServlet</servlet-link> </service-impl-bean> </port-component> </webservice-description> </webservices>
<?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd"> <endpoint-config> <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name> <property> <property-name>cxf.interceptors.in</property-name> <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value> </property> <property> <property-name>cxf.interceptors.out</property-name> <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value> </property> </endpoint-config> </jaxws-config>
<?xml version="1.0" encoding="UTF-8"?> <jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd"> <endpoint-config> <config-name>Custom FI Config</config-name> <property> <property-name>cxf.features</property-name> <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value> </property> </endpoint-config> </jaxws-config>
import org.apache.cxf.frontend.ClientProxy; import org.apache.cxf.transport.http.HTTPConduit; import org.apache.cxf.transports.http.configuration.HTTPClientPolicy; // Set chunking threshold before using a JAX-WS port client HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit(); HTTPClientPolicy client = conduit.getClient(); client.setChunkingThreshold(8192);
protected Service(URL wsdlDocumentLocation, QName serviceName, WebServiceFeature... features)
<?xml version="1.0" encoding="UTF-8"?> <messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0"> <hornetq-server> <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations> </hornetq-server> </messaging-deployment>
<?xml version="1.0" encoding="UTF-8"?> <messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0"> <server> <jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations> </server> </messaging-deployment>
<dependency> <groupId>org.jboss.eap</groupId> <artifactId>wildfly-client-properties</artifactId> </dependency>
org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: <OBJECT> of media type:
@Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } }
import jakarta.ws.rs.Produces; @Path("dates") public class DateService { @GET @Path("daysuntil/{targetdate}") @Produces(MediaType.TEXT_PLAIN) public long showDaysUntil(@PathParam("targetdate") String targetDate) { DateLogger.LOGGER.logDaysUntilRequest(targetDate); final long days; try { final LocalDate date = LocalDate.parse(targetDate, DateTimeFormatter.ISO_DATE); days = ChronoUnit.DAYS.between(LocalDate.now(), date); } catch (DateTimeParseException ex) { // ** DISCLAIMER **. This example is contrived. throw new WebApplicationException(Response.status(400).entity(ex.getLocalizedMessage()).type(MediaType.TEXT_PLAIN) .build()); } return days; } }
ClientRequest request = new ClientRequest(generateURL("/linkheader/str")); request.addLink("previous chapter", "previous", "http://example.com/TheBook/chapter2", null); ClientResponse response = request.post(); LinkHeader header = response.getLinkHeader();
ResteasyClient client = new ResteasyClientBuilder().build(); Response response = client.target(generateURL("/linkheader/str")).request() .header("Link", "<http://example.com/TheBook/chapter2>; rel=\"previous\"; title=\"previous chapter\"").post(Entity.text(new String())); jakarta.ws.rs.core.Link link = response.getLink("previous");
@Path("myResource") public class ExampleSubResources { @POST @Path("items") @Produces("text/plain") public Response anotherResource(String text) { return Response.ok("ok").build(); } @Path("items") @Produces("text/plain") public SubResource anotherResourceLocator() { return new SubResource(); } }
<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure> <deployment> <exclusions> <module name="org.jboss.resteasy.resteasy-jackson2-provider"/> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> </exclusions> <dependencies> <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/> </dependencies> </deployment> </jboss-deployment-structure>
Dependencies: com.company.my-ejb annotations, com.company.other
<jboss-deployment-structure> <deployment> <dependencies> <module name="com.company.my-ejb" annotations="true"/> <module name="com.company.other"/> </dependencies> </deployment> </jboss-deployment-structure>
<jboss-deployment-structure> <deployment> <transformers> <transformer class="org.jboss.as.hibernate.Hibernate51CompatibilityTransformer"/> </transformers> </deployment> <sub-deployment name="main.war"> <transformers> <transformer class="org.jboss.as.hibernate.Hibernate51CompatibilityTransformer"/> </transformers> </sub-deployment> </jboss-deployment-structure>
import jakarta.persistence.Column; import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.Id; import jakarta.persistence.Table; @Entity // User is a keyword in some SQL dialects! @Table(name = "MyUsers") public class MyUser { @Id @GeneratedValue private Long id; @Column(unique = true) private String username; private String firstName; private String lastName; public Long getId() { return id; } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; }
<persistence xmlns="https://jakarta.ee/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_0.xsd" version="3.0"> <persistence-unit name="my-unique-persistence-unit-name"> <properties> // properties </properties> </persistence-unit> </persistence>
<?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="EAP5_COMPAT_PU"> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source> <properties> <property name="jboss.as.jpa.deferdetach" value="true" /> </properties> </persistence-unit> </persistence>
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=default remote.connection.default.host=localhost remote.connection.default.port=4447 remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=default remote.connection.default.host=localhost remote.connection.default.port=8080 remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.protocol=remote
java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory java.naming.provider.url=remote://localhost:4447
java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory java.naming.provider.url=http-remoting://localhost:8080
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=one remote.connection.one.port=8080 remote.connection.one.host=127.0.0.1 remote.connection.one.username=quickuser remote.connection.one.password=quick-123
<configuration> <authentication-client xmlns="urn:elytron:client:1.7"> <authentication-rules> <rule use-configuration="ejb"/> </authentication-rules> <authentication-configurations> <configuration name="ejb"> <set-user-name name="quickuser"/> <credentials> <clear-password password="quick-123"/> </credentials> </configuration> </authentication-configurations> </authentication-client> <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.2"> <connections> <connection uri="remote+http://127.0.0.1:8080" /> </connections> </jboss-ejb-client> </configuration>
<jboss-web> <valve> <class-name>org.jboss.examples.MyValve</class-name> <param> <param-name>myParam</param-name> <param-value>foobar</param-value> </param> </valve> </jboss-web>
<exports> <exclude path="com/mycompany/duplicateclassespath/"/> </exports>
<resource-root path="mycompany.jar"> <filter> <exclude path="com/mycompany/duplicateclassespath"/> </filter> </resource-root>
<jboss-web> <max-active-sessions>...</max-active-sessions> <replication-config> <replication-granularity>...</replication-granularity> <cache-name>...</cache-name> </replication-config> </jboss-web>
<?xml version="1.0" encoding="UTF-8"?> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <session-management name="foo"/> </distributable-web>
<?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <session-management name="foo"/> </distributable-web> </jboss>
<?xml version="1.0" encoding="UTF-8"?> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <infinispan-session-management cache-container="foo" cache="bar" granularity="SESSION"> <primary-owner-affinity/> </infinispan-session-management> </distributable-web>
<?xml version="1.0" encoding="UTF-8"?> <jboss xmlns="urn:jboss:1.0"> <distributable-web xmlns="urn:jboss:distributable-web:1.0"> <infinispan-session-management cache-container="foo" cache="bar" granularity="ATTRIBUTE"> <local-affinity/> </infinispan-session-management> </distributable-web> </jboss>
@Stateful @Clustered public class MyBean implements MySessionInt { public void myMethod() { // } }
<c:clustering> <ejb-name>DDBasedClusteredSFSB</ejb-name> <c:clustered>true</c:clustered> </c:clustering>
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar:add(archive=wmq.jakarta.jmsra.rar, transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=test/connection-definitions=test:write-attribute(name=recovery-security-domain,value=myDomain)
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar:add(archive=wmq.jakarta.jmsra.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=queue-ao:add(class-name=com.ibm.mq.jakarta.connector.outbound.MQQueueProxy, jndi-name=java:jboss/MQ_QUEUE_NAME) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=queue-ao/config-properties=baseQueueName:add(value= MQ_QUEUE_NAME ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=queue-ao/config-properties=baseQueueManagerName:add(value= MQ_QUEUE_MANAGER )
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=topic-ao:add(class-name=com.ibm.mq.jakarta.connector.outbound.MQTopicProxy, jndi-name=java:jboss/MQ_TOPIC_NAME) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=topic-ao/config-properties=baseTopicName:add(value= MQ_TOPIC_NAME ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/admin-objects=topic-ao/config-properties=brokerPubQueueManager:add(value= MQ_QUEUE_MANAGER )
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd:add(class-name=com.ibm.mq.jakarta.connector.outbound.ManagedConnectionFactoryImpl, jndi-name=java:jboss/MQ_CONNECTIONFACTORY_NAME, tracking=false) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd/config-properties=hostName:add(value= MQ_HOST_NAME ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd/config-properties=port:add(value= MQ_PORT ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd/config-properties=channel:add(value= MQ_CHANNEL_NAME ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd/config-properties=transportType:add(value= MQ_CLIENT ) /subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar/connection-definitions=mq-cd/config-properties=queueManager:add(value= MQ_QUEUE_MANAGER )
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name,value=wmq.jakarta.jmsra.rar)
@MessageDriven(name="IbmMqMdb", activationConfig = { @ActivationConfigProperty(propertyName = "destinationType",propertyValue = "jakarta.jms.Queue"), @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"), @ActivationConfigProperty(propertyName = "hostName", propertyValue = " MQ_HOST_NAME "), @ActivationConfigProperty(propertyName = "port", propertyValue = " MQ_PORT "), @ActivationConfigProperty(propertyName = "channel", propertyValue = " MQ_CHANNEL_NAME "), @ActivationConfigProperty(propertyName = "queueManager", propertyValue = " MQ_QUEUE_MANAGER "), @ActivationConfigProperty(propertyName = "destination", propertyValue = " MQ_QUEUE_NAME "), @ActivationConfigProperty(propertyName = "transportType", propertyValue = " MQ_CLIENT ") }) @ResourceAdapter(value = "wmq.jakarta.jmsra-VERSION.rar") @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) public class IbmMqMdb implements MessageListener { }
/subsystem=resource-adapters/resource-adapter=wmq.jakarta.jmsra.rar:activate()
@ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE")
@JMSConnectionFactoryDefinition( name = "java:/jms/WMQConnectionFactory", interfaceName = "javax.jms.ConnectionFactory", resourceAdapter = "wmq.jmsra", properties = { "channel=<channel>", "hostName=<hostname_wmq_broker>", "transportType=<transport_type>", "queueManager=<queue_manager>" } )
@Inject @JMSConnectionFactory("jms/CF") @JMSPasswordCredential(userName="myusername", password="mypassword") @JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE) transient JMSContext context3;
WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (EJB default - 7) IJ000604: Throwable while attempting to get a new connection: null: com.ibm.mq.connector.DetailedResourceException: MQJCA1011: Failed to allocate a JMS connection., error code: MQJCA1011 An internal error caused an attempt to allocate a connection to fail. See the linked exception for details of the failure.
QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword");
SVR-ERROR: Expected JMSException, received com.ibm.mq.connector.outbound.MQQueueProxy cannot be cast to com.ibm.mq.jms.MQDestination
ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jmsServlet-1.0-SNAPSHOT/: com.ibm.msg.client.jms.DetailedJMSRuntimeException: MQJCA0002: An exception occurred in the IBM MQ layer. See the linked exception for details. A call to IBM MQ classes for Java(tm) caused an exception to be thrown.
SVR-ERROR: com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ2007: Failed to send a message to destination ' MDB_NAME TOPIC_NAME '
com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2072' ('MQRC_SYNCPOINT_NOT_AVAILABLE')
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <exclude-subsystems> <subsystem name="logging"/> </exclude-subsystems> </deployment> </jboss-deployment-structure>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <sub-deployment name="example.war"> <exclude-subsystems> <subsystem name="logging"/> </exclude-subsystems> </sub-deployment> </jboss-deployment-structure>
/subsystem=logging:write-attribute(name="add-logging-api-dependencies", value="false")
<subsystem xmlns="urn:jboss:domain:logging:8.0"> <add-logging-api-dependencies value="false"/> </subsystem>