Chapter 6. Miscellaneous Changes

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.

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.

For details on deploying JBoss EAP 7 on Amazon EC2, see Deploying JBoss EAP on Amazon Web Services.

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.

WFLYCTL0184:    New missing/unsatisfied dependencies

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.

$ mvn wildfly:undeploy

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.

$ mvn wildfly:undeploy -pl application-A,application-B
$ mvn wildfly:undeploy -pl data-shared

This new undeploy behavior is more correct and ensures that you do not end up in an unstable deployment state.

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.

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.

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.

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 previous 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.

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.