Chapter 6. Miscellaneous Changes 6.1. Changes to Delivery of JBoss EAP Natives and Apache HTTP Server JBoss EAP 7 natives are delivered differently in this release than in the past. Some now ship with the new Red Hat JBoss Core Services product, which is a set of supplementary software that is common to many of the Red Hat JBoss middleware products. The new product allows for faster distribution of updates and a more consistent update experience. The JBoss Core Services product is available for download in a different location on the Red Hat Customer Portal. The following table lists the differences in the delivery methods between the releases. Package JBoss EAP 6 JBoss EAP 7 AIO Natives for Messaging Delivered with the product in a separate "Native Utilities" download Included within the JBoss EAP distribution. No additional download is required. Apache HTTP Server Delivered with the product in a separate "Apache HTTP Server" download Delivered with the new JBoss Core Services product mod_cluster, mod_jk, isapi, and nsapi connectors Delivered with the product in a separate "Webserver Connector Natives" download Delivered with the new JBoss Core Services product JSVC Delivered with the product in a separate "Native Utilities" download Delivered with the new JBoss Core Services product OpenSSL Delivered with the product in a separate "Native Utilities" download Delivered with the new JBoss Core Services product tcnatives Delivered with the product in a separate "Native Components" download This was dropped in JBoss EAP 7 You should also be aware of the following changes: Support was dropped for mod_cluster and mod_jk connectors used with Apache HTTP Server from Red Hat Enterprise Linux RPM channels. If you run Apache HTTP Server from Red Hat Enterprise Linux RPM channels and need to configure load balancing for JBoss EAP 7 servers, you can do one of the following: Use the Apache HTTP Server provided by JBoss Core Services. You can configure JBoss EAP 7 to act as a front-end load balancer. For more information, see Configuring JBoss EAP as a Front-end Load Balancer in the JBoss EAP Configuration Guide . You can deploy Apache HTTP Server on a machine that is supported and certified and then run the load balancer on that machine. For the list of supported configurations, see Overview of HTTP Connectors in the JBoss EAP 7 Configuration Guide . You can find more information about JBoss Core Services in the Apache HTTP Server Installation Guide . 6.2. Changes to Deployments on Amazon EC2 A number of changes have been made to the Amazon Machine Images (AMI) in JBoss EAP 7. This section briefly summarizes some of those changes. The way you launch non-clustered and clustered JBoss EAP instances and domains in Amazon EC2 has changed significantly. JBoss EAP 6 used the User Data: field for JBoss EAP configuration. The AMI scripts that parsed the configuration in the User Data: field and started the servers automatically on instance startup have been removed from JBoss EAP 7. Red Hat JBoss Operations Network agent was installed in the release of JBoss EAP. In JBoss EAP 7, you must install it separately. For details on deploying JBoss EAP 7 on Amazon EC2, see Deploying JBoss EAP on Amazon Web Services . 6.3. Undeploying Applications That Include Shared Modules Changes in the JBoss EAP 7.1 server and the Maven plug-in can result in the following failure when you attempt to undeploy your application. This error can occur if your application contains modules that interact with or depend on each other. For example, assume you have an application that contains two Maven WAR project modules, application-A and application-B , that share data managed by the data-sharing module. When you deploy this application, you must deploy the shared data-sharing module first, and then deploy the modules that depend on it. The deployment order is specified in the <modules> element of the parent pom.xml file. This is true in JBoss EAP 6.4 through JBoss EAP 7.4. In releases prior to JBoss EAP 7.1, you could undeploy all of the archives for this application from the root of the parent project using the following command. In JBoss EAP 7.1 and later, you must first undeploy the archives that use the shared modules, and then undeploy the shared modules. Since there is no way to specify the order of undeployment in the project pom.xml file, you must undeploy the modules manually. You can accomplish this by running the following commands from the root of the parent directory. This new undeploy behavior is more correct and ensures that you do not end up in an unstable deployment state. 6.4. Changes to JBoss EAP Scripts The add-user script behavior has changed in JBoss EAP 7 due to a change in password policy. JBoss EAP 6 had a strict password policy. As a result, the add-user script rejected weak passwords that did not satisfy the minimum requirements. In JBoss EAP 7, weak passwords are accepted and a warning is issued. For more information, see Setting Add-User Utility Password Restrictions in the JBoss EAP Configuration Guide . 6.5. Removal of OSGi Support When JBoss EAP 6.0 GA was first released, JBoss OSGi, an implementation of the OSGi specification, was included as a Technology Preview feature. With the release of JBoss EAP 6.1.0, JBoss OSGi was demoted from Technology Preview to Unsupported. In JBoss EAP 6.1.0, the configadmin and osgi extension modules and subsystem configuration for a standalone server were moved to a separate EAP_HOME /standalone/configuration/standalone-osgi.xml configuration file. Because you should not migrate this unsupported configuration file, the removal of JBoss OSGi support should not impact the migration of a standalone server configuration. If you modified any of the other standalone configuration files to configure osgi or configadmin , those configurations must be removed. For a managed domain, the osgi extension and subsystem configuration were removed from the EAP_HOME /domain/configuration/domain.xml file in the JBoss EAP 6.1.0 release. However, the configadmin module extension and subsystem configuration remain in the EAP_HOME /domain/configuration/domain.xml file. This configuration is no longer supported in JBoss EAP 7 and must be removed. 6.6. Changes to Java Platform Module System Names Standalone Java applications that use the JPMS architecture require code updates due to Java Platform Module System (JPMS) name changes in JBoss EAP 7.3. Update your standalone application code with the new JPMS module names to work properly with JBoss EAP 7.3. The change in JPMS module names only affects standalone applications, therefore no code updates are required to the JBoss EAP applications deployed on the server. Table 6.1. JPMS Name Changes GroupID JBoss EAP 7.2 JBoss EAP 7.3 org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_2.1_spec beta.jboss.jaxrs.api_2_1 java.ws.rs org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec beta.jboss.jacc.api_1_5 java.security.jacc org.jboss.spec.javax.security.auth.message:jboss-jaspi-api_1.1_spec beta.jboss.jaspi.api_1_1 java.security.auth.message 6.7. Changes in SOAP with Attachments API for Java Update the user-defined SOAP handlers to comply with the SAAJ 1.4 specification when migrating to JBoss EAP 7.3. As JBoss EAP 7.3 ships with SAAJ 1.4, SOAP handlers written for the release of JBoss EAP, which shipped with SAAJ 1.3, might not work correctly due to the differences in SAAJ 1.4 and 1.3 specifications. For information about SAAJ 1.4, see SOAP with Attachments . While updating the SOAP handlers, SAAJ 1.3 can be used in JBoss EAP 7.3 by setting the system property -Djboss.saaj.api.version=1.3 . After the SOAP handlers are updated, remove the system property to restore the default functionality. 6.8. Maven Artifact Changes for Jakarta EE Some javax Maven artifacts have been replaced with jakarta Maven artifacts for JBoss EAP 7.3. You must update your project dependencies with the new jakarta Maven artifacts when building your projects for JBoss EAP 7.3. Not updating project dependencies will cause build failures when building the projects for JBoss EAP 7.3. For information about managing project dependencies, see Manage Project Dependencies in the Development Guide . The following table lists the javax artifacts and the jakarta artifacts that replaced them in JBoss EAP 7.3. Table 6.2. javax artifacts and jakarta artifacts replacing them javax artifact jakarta artifact com.sun.mail:javax.mail com.sun.mail:jakarta.mail javax.activation:activation com.sun.activation:jakarta.atcivation javax.enterprise:cdi-api jakarta.enterprise:jakarta.enterprise.cdi-api javax.inject:javax.inject jakarta.inject:jakarta.inject-api javax.json:javax.json-api jakarta.json:jakarta.json-api javax.json.bind:javax.json.bind-api jakarta.json.bind:jakarta.json.bind-api javax.persistence:javax.persistence-api jakarta.persistence:jakarta.persistence-api javax.security.enterprise:javax.security.enterprise-api jakarta.security.enterprise:jakarta.security.enterprise-api javax.validation:validation-api jakarta.validation:jakarta.validation-api org.glassfish:javax.json org.glassfish:jakarta.json org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.3_spec org.jboss.spec.javax.xml.soap:jboss-saaj-api_1.4_spec org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec org.jboss.spec.javax.transaction:jboss-transaction-api_1.3_spec Note com.sun.mail:jakarta.mail brings in Jakarta Mail 1.6.4 library. For information about Jakarta Mail compatibility, see Compatibility Notes maintained by Eclipse.

Commands:
WFLYCTL0184: New missing/unsatisfied dependencies
mvn wildfly:undeploy
mvn wildfly:undeploy -pl application-A,application-B mvn wildfly:undeploy -pl data-shared