Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 6. Server migration changes

Before migrating, ensure you understand the migration changes necessary for deploying applications on a server and upgrading them in Red Hat JBoss Enterprise Application Platform 8.0.

6.1. Web server configuration changes

Learn about changes in mod_cluster and Undertow within Red Hat JBoss Enterprise Application Platform that impact root context behavior and enhance the security of your server information.

6.1.1. Default web module behavior changes

In JBoss EAP 7.0, the root context of a web application was disabled by default in mod_cluster.

As of JBoss EAP 7.1, this is no longer the case. This can have unexpected consequences if you are expecting the root context to be disabled. For example, requests can be misrouted to undesired nodes or a private application that should not be exposed can be inadvertently accessible through a public proxy. Undertow locations are also now registered with the mod_cluster load balancer automatically unless they are explicitly excluded.

Use the following management CLI command to exclude ROOT from the modcluster subsystem configuration.

Copy to Clipboard Toggle word wrap 
/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

Use the following management CLI command to disable the default welcome web application.

Copy to Clipboard Toggle word wrap 
/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

Additional resources

6.1.2. Undertow subsystem default configuration changes

Prior to Red Hat JBoss Enterprise Application Platform 7.2, the default undertow subsystem configuration included two response header filters that were appended to each HTTP response by the default-host:

  • Server was previously set to JBoss EAP/7.
  • X-Powered-By was previously set to Undertow/1.

These response header filters were removed from the default JBoss EAP 7.2 configuration to prevent inadvertent disclosure of information about the server in use.

The following is an example of the default undertow subsystem configuration in JBoss EAP 7.1.

Copy to Clipboard Toggle word wrap 
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

The following is an example of the default undertow subsystem configuration in JBoss EAP 7.4.

Copy to Clipboard Toggle word wrap 
<subsystem xmlns="urn:jboss:domain:undertow:12.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>

The following is an example of the default undertow subsystem configuration in JBoss EAP 8.0.

Copy to Clipboard Toggle word wrap 
<subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}" default-security-domain="other">
    <byte-buffer-pool name="default"/>
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" ssl-context="applicationSSC" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker http-authentication-factory="application-http-authentication"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <application-security-domains>
        <application-security-domain name="other" security-domain="ApplicationDomain"/>
    </application-security-domains>
</subsystem>

6.2. Infinispan server configuration changes

Configure a custom stateful session bean (SFSB) cache for passivation in Red Hat JBoss Enterprise Application Platform 7.1 and later while considering the following aspects:

  • Deprecation of the idle-timeout attribute
  • Implementation of lazy passivation
  • Determination of cluster name
  • Appropriate configuration of eviction and expiration
  • Modifications in the cache container transport protocol for enhanced performance.

By adhering to these considerations, you can optimize your SFSB cache configuration for improved passivation in JBoss EAP 7.1 and beyond.

6.2.1. Configuring custom stateful session bean cache for passivation

In JBoss EAP 7.1 and later versions, a custom stateful session beans (SFSB) cache with passivation enabled has changed. When configuring SFSB cache with passivation, consider the following key changes:

  • Deprecation of the idle-timeout attribute
  • A shift from eager to lazy passivation
  • Determining the cluster name
  • Configuring eviction and expiration in the Jakarta Enterprise Beans cache

When configuring a custom SFSB cache for passivation in JBoss EAP 7.1 and later versions, consider the following restrictions:

  • The idle-timeout attribute, which is configured in the infinispan passivation-store of the ejb3 subsystem, is deprecated in JBoss EAP 7.1 and later. JBoss EAP 7.1 and later only support lazy passivation, which occurs when the max-size threshold is reached.

    Note

    Eager passivation through idle-timeout is no longer supported in these versions.

  • In JBoss EAP 7.1 and later, the cluster name used by the Jakarta Enterprise Beans client is determined by the actual cluster name of the channel, as configured in the jgroups subsystem.
  • JBoss EAP 7.1 and later still allow you to set the max-size attribute to control the passivation threshold.

6.2.2. Infinispan cache container transport changes

A behavior change between JBoss EAP 7.0 and later versions requires performing updates to the cache container transport protocol in batch mode or using a special header. This change also affects tools used for managing the JBoss EAP server.

The following is an example of the management CLI commands used to configure the cache container transport protocol in JBoss EAP 7.0.

Copy to Clipboard Toggle word wrap 
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

The following is an example of the management CLI commands needed to perform the same configuration in JBoss EAP 7.1. Note that the commands are executed in batch mode.

Copy to Clipboard Toggle word wrap 
batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

If you prefer not to use batch mode, you can instead specify the operation header allow-resource-service-restart=true when defining the transport.

If you use scripts to update the cache container transport protocol, be sure to review them and add batch mode.

6.2.3. EJB subsystem configuration changes from version 8.0 and later

JBoss EAP 8.0 introduces changes to the Enterprise JavaBeans (EJB) subsystem configuration for distributable stateful session beans (SFSB), including a new subsystem and updates to several resources. Several resources used in JBoss EAP 6 and 7 are also deprecated. These changes enable server configuration migration to ensure that your applications are compatible with future major releases.

JBoss EAP 8.0 replaces the deprecated resources used in JBoss EAP 6 and 7 with two new resources and a distributable-ejb subsystem for configuring SFSB caching distributively. The following table outlines the deprecated resources and the new resources that replace them.

Table 6.1. SFSB cache configuration changes
Deprecated resourcesNew non-distributable SFSB cacheNew distributable SFSB cache

/subsystem=ejb3/cache

/subsystem=ejb3/simple-cache

/subsystem=ejb3/distributable-cache

/subsystem=ejb3/passivation-store

NA

/subsystem=ejb3/distributable-cache=”name”/bean-management"=..

Non-distributable SFSB cache, /subsystem=ejb3/simple-cache, is equivalent to the SFSB cache, /subsystem=ejb3/cache, used in JBoss EAP 7, where no passivation store was defined.

Distributable SFSB cache, /subsystem=ejb3/distributable-cache, includes an optional bean-management attribute that refers to a corresponding resource from the distributable-ejb subsystem. If you do not define the resource, it defaults to the bean-management resource within the distributable-ejb subsystem.

Consider migrating your server configuration to the updated approach in JBoss EAP 8.0. Although the current release continues to function with the deprecated resources, this might not be the case with future releases when they get removed.

An example of a comparison between JBoss EAP 7 and preferred JBoss EAP 8.0 configurations is as follows:

JBoss EAP 7 configuration:

Copy to Clipboard Toggle word wrap 
/subsystem=ejb3/cache=example-simple-cache:add()
/subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, bean-cache=default, max-size=1024)
/subsystem=ejb3/cache=example-distributed-cache:add(passivation-store=infinispan)

Preferred JBoss EAP 8.0 configuration:

Copy to Clipboard Toggle word wrap 
/subsystem=ejb3/simple-cache=example-simple-cache:add()
/subsystem=distributable-ejb=example-distributed-cache/infinispan-bean-management=example-bean-cache:add(cache-container=ejb, cache=default, max-active-beans=1024)
/subsystem=ejb3/distributable-cache=example-distributed-cache:add(bean-management=example-bean-cache)

Adopting the preferred JBoss EAP 8.0 configuration ensures that your servers are compatible with the latest version and future major releases. You will also benefit from improved resources and subsystems for distributable SFSBs.

6.3. Jakarta Enterprise Beans server configuration changes

While configuring the ejb3 subsystem in JBoss EAP 7, exceptions may appear in the server log during deployment of enterprise bean applications.

Important

If you use the JBoss Server Migration Tool to update your server configuration, ensure that the ejb3 subsystem is properly configured and no issues arise when deploying your Jakarta Enterprise Beans applications. For information about configuring and running the tool, see Using the JBoss Server Migration Tool.

6.3.1. Resolving DuplicateServiceException due to caching changes

The following DuplicateServiceException error is caused by caching changes in JBoss EAP 7.

DuplicateServiceException in server log

Copy to Clipboard Toggle word wrap 
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Failed to start service
...
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered

To resolve the DuplicateServiceException caused by caching changes in JBoss EAP 7, run the following commands to reconfigure caching in the ejb3 subsystem.

Copy to Clipboard Toggle word wrap 
/subsystem=ejb3/file-passivation-store=file:remove
/subsystem=ejb3/cluster-passivation-store=infinispan:remove
/subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, max-size=10000)

/subsystem=ejb3/cache=passivating:remove
/subsystem=ejb3/cache=clustered:remove
/subsystem=ejb3/cache=distributable:add(passivation-store=infinispan, aliases=[passivating, clustered])

By reconfiguring the cache, you can resolve this error and prevent the DuplicateServiceException from occurring.

6.4. Messaging server configuration changes

Learn how to migrate both your configuration and associated messaging data to ActiveMQ Artemis, which serves as the Jakarta Messaging support provider in Red Hat JBoss Enterprise Application Platform 8.0.

6.4.1. Migrate messaging data

Review the approaches you can take to migrate messaging data in Red Hat JBoss Enterprise Application Platform.

To migrate messaging data from a previous JBoss EAP 7.x release to JBoss EAP 8.0, you can Migrate messaging data by using export and import approaches. This method involves exporting messaging data from the previous release and importing it into JBoss EAP 8.0 using the management CLI import-journal operation. Note that this approach is specifically applicable to file-based messaging systems.

As with version 7, JBoss EAP 8.0 continues to use ActiveMQ Artemis as the Jakarta Messaging support provider, which helps to make the migration process smoother.

6.4.1.1. Migrate messaging data by using export and import approaches

Use the following approach to export the messaging data from a previous release to an XML file, and then import that file using the import-journal operation:

  1. Export messaging data from JBoss EAP 7.x. release
  2. Import the XML formatted messaging data
Important

You cannot use the export and import method to move messaging data between systems that use a JDBC-based journal for storage.

6.4.1.1.1. Export messaging data from JBoss EAP 7.x release

To export messaging data from Red Hat JBoss Enterprise Application Platform 7.x release, follow the outlined procedure.

Prerequisites

  • JBoss EAP 7.x is installed on your system.
  • You have access to a terminal or command line interface.
  • You have the necessary permissions to navigate directories and execute commands.

Procedure

  1. Open a terminal, navigate to the JBoss EAP 7.x install directory, and start the server in admin-only mode.

    Copy to Clipboard Toggle word wrap 
    $ EAP_HOME/bin/standalone.sh -c standalone-full.xml --start-mode=admin-only

  2. Open a new terminal, navigate to the JBoss EAP 7.x install directory, and connect to the management CLI.

    Copy to Clipboard Toggle word wrap 
    $ EAP_HOME/bin/jboss-cli.sh --connect

  3. Use the following management CLI command to export the messaging journal data.

    Copy to Clipboard Toggle word wrap 
    /subsystem=messaging-activemq/server=default:export-journal()

Verification

  • Make sure there are no errors or warning messages in the log at the completion of the command.
  • Use tool compatible with your operating system to validate the XML in the generated output file.
6.4.1.1.2. Import the XML formatted messaging data

After exporting messaging data from a JBoss EAP 8.0, you need to import the XML file into JBoss EAP 8.0 or later using the import-journal operation.

Prerequisites

  • Complete the migration of your JBoss EAP 8.0 by using either the management CLI migrate operation or the JBoss Server Migration Tool.
  • Start the JBoss EAP 8.0 server in normal mode without any connected Jakarta Messaging clients.

Procedure

To import the XML file into JBoss EAP 8.0 or a later version, follow these steps using the import-journal operation:

Important

If your target server has already performed some messaging tasks, make sure to back up your messaging folders before you begin the import-journal operation to prevent data loss in the event of an import failure. For more information, see Backing up messaging folder data.

  1. Start the JBoss EAP 8.0 server in normal mode with no Jakarta Messaging clients connected.

    Important

    It is important that you start the server with no Jakarta Messaging clients connected. This is because the import-journal operation behaves like a Jakarta Messaging producer. Messages are immediately available when the operation is in progress. If this operation fails in the middle of the import and Jakarta Messaging clients are connected, there is no way to recover because Jakarta Messaging clients might have already consumed some of the messages.

  2. Open a new terminal, navigate to the JBoss EAP 8.0 install directory, and connect to the management CLI.

    Copy to Clipboard Toggle word wrap 
    $ EAP_HOME/bin/jboss-cli.sh --connect

  3. Use the following management CLI command to import the messaging data:

    Copy to Clipboard Toggle word wrap 
    /subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)
    Important

    Do not run this command more than one time as doing so will result in duplicate messages.

6.4.1.1.3. Recovering from an import messaging data failure

You can recover from an import messaging data failure if the import-journal operation fails.

Prerequisites

  • Familiarity with the JBoss EAP 8.0 server and its management CLI commands.
  • Knowledge of the directory location of messaging journal folders.
  • Prior backup of target server messaging data if available.

Procedure

  1. Shut down the JBoss EAP 8.0 server.
  2. Delete all of the messaging journal folders. See Backing up messaging folder data for the management CLI commands to determine the correct directory location for the messaging journal folders.
  3. If you backed up the target server messaging data prior to the import, copy the messaging folders from the backup location to the messaging journal directory determined in the prior step.
  4. Repeat the steps to Import the XML formatted messaging data.

6.4.1.2. Migrate messaging data using a messaging bridge

A Jakarta Messaging bridge consumes messages from a source Jakarta Messaging queue or topic and sends them to a target Jakarta Messaging queue or topic, located on a different server. It enables message bridging between messaging servers that adhere to the Jakarta Messaging 3.1 standards. Look up the source and destination Jakarta Messaging resources using Java Naming and Directory Interface, ensuring that the client classes for Java Naming and Directory Interface lookup are bundled in a module and declare the module name in the Jakarta Messaging bridge configuration.

This section provides instructions on how to configure the servers and deploy a messaging bridge for moving messaging data from JBoss EAP 7 to JBoss EAP 8.0. To achieve this, proceed with the following steps:

  1. Configuring JBoss EAP 8.0 server
  2. Migrating the messaging data
6.4.1.2.1. Configuring JBoss EAP 8.0 server

To configure the Jakarta Messaging bridge in JBoss EAP 8.0 for seamless migration of messaging data, including module dependencies and queue configuration, follow the outlined procedure.

Prerequisites

  • JBoss EAP 8.0 server installed and running.

Procedure

  1. Create the following jms-queue configuration for the default server in the messaging-activemq subsystem of the JBoss EAP 8.0 server.

    Copy to Clipboard Toggle word wrap 
    jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]

  2. Make sure that messaging-activemq subsystem default server contains a configuration for the InVmConnectionFactory connection-factory similar to the following:

    Copy to Clipboard Toggle word wrap 
    <connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>

    If it does not contain the entry, create one using the following management CLI command:

    Copy to Clipboard Toggle word wrap 
    /subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])

  3. Create and deploy a Jakarta Messaging bridge that reads messages from the InQueue JMS queue and transfers them to the MigratedMessagesQueue configured on the JBoss EAP 7.x server.

    Copy to Clipboard Toggle word wrap 
    /subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.wildfly.naming.client.WildFlyInitialContextFactory"),("java.naming.provider.url"=>"http-remoting://legacy-host:8080")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)

    This creates the following jms-bridge configuration in the messaging-activemq subsystem of the JBoss EAP 8.0 server.

    Copy to Clipboard Toggle word wrap 
    <jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE">
    <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory">
        <source-context>
            <property name="java.naming.factory.initial" value="org.wildfly.naming.client.WildFlyInitialContextFactory"/>
            <property name="java.naming.provider.url" value="http-remoting://legacy-host:8080"/>
        </source-context>
    </source>
    <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/>
</jms-bridge>
6.4.1.2.2. Migrating the messaging data

To migrate messaging data from Red Hat JBoss Enterprise Application Platform 8.0 to Red Hat JBoss Enterprise Application Platform 8.0, follow the outlined procedure.

Prerequisites

  • JBoss EAP 8.0 server installed and running.

Procedure

  1. Verify that the information you provided for the following configurations is correct.

    • Any queue and topic names.
    • The java.naming.provider.url for Java Naming and Directory Interface lookup.
  2. Make sure that you have deployed the target Jakarta Messaging destination to the JBoss EAP 8.0 server.
  3. Start the JBoss EAP 8.0 servers, including the JBoss EAP 7 servers involved in the migration process.

6.4.1.3. Backing up messaging folder data

To ensure data integrity, it is recommended to back up the target message folders before making any changes if your server has already processed messages. You can find the default location of the messaging folders at EAP_HOME/standalone/data/activemq/; however, it might be configurable. If you are unsure about the location of your messaging data, you can use the following management CLI commands to determine it.

Procedure

  1. Determine the location of your messaging data by using the following management CLI commands:

    Copy to Clipboard Toggle word wrap 
    /subsystem=messaging-activemq/server=default/path=journal-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path
    Note

    Ensure that you stop the server before copying the data.

  2. Copy each messaging folder to a secure backup location after you identify their respective locations.

6.4.2. Configure the Jakarta Messaging resource adapter

The way you configure a generic Jakarta Messaging resource adapter for use with a third-party Jakarta Messaging provider has changed in Red Hat JBoss Enterprise Application Platform 8.0. For more information, see Deploying a generic Java Message Service resource adapter in the JBoss EAP 7.4 Configuring Messaging guide.

6.4.3. Messaging configuration changes

In Red Hat JBoss Enterprise Application Platform 7.0, if you configured the replication-primary policy without specifying the check-for-live-server attribute, its default value was set to false. This has changed in JBoss EAP 7.1 and later. The default value for the check-for-live-server attribute is now set to true.

The following is an example of a management CLI command that configures the replication-primary policy without specifying the check-for-live-server attribute.

Copy to Clipboard Toggle word wrap 
/subsystem=messaging-activemq/server=default/ha-policy=replication-primary:add(cluster-name=my-cluster,group-name=group1)

When you read the resource using the management CLI, note that the check-for-live-server attribute value is set to true.

Copy to Clipboard Toggle word wrap 
/subsystem=messaging-activemq/server=default/ha-policy=replication-primary:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

6.4.4. Galleon layer for embedded broker messaging

In JBoss EAP 7, an embedded messaging broker was part of the default installation. In JBoss EAP 8, this functionality was added to a new Galleon layer called as embedded-activemq.

This new layer is not a part of the default configuration so users who want to rely on having a broker embedded in JBoss EAP must include it explicitly in their configuration.

The layer provides a messaging-activemq subsystem with an embedded broker even if it is recommended for customers to use a dedicated AMQ cluster on OpenShift. It also provisions ancillary resources, for example, socket-bindings and necessary dependencies needed to support this use case.

6.5. Security enhancements in JBoss EAP 8.0

Starting with JBoss EAP 8.0, you must use Elytron since the legacy security subsystem and legacy security realms are no longer available. You can only configure Elytron defaults by using the JBoss Server Migration Tool. Therefore, legacy security configurations must be manually migrated.

Additional resources

6.5.1. Vaults migration

Vaults has been removed from JBoss EAP 8.0. Use the credential store provided by the elytron subsystem to store sensitive strings.

Additional resources

6.5.2. Legacy security subsystem and security realms removal

The legacy security subsystem and legacy security realms have been removed from JBoss EAP 8.0. Use the security realms provided by the elytron subsystem.

Additional resources

6.5.4. Migrate from Red Hat build of Keycloak OIDC client adapter to JBoss EAP subsystem

The keycloak subsystem is not supported in JBoss EAP 8.0 and is replaced by the elytron-oidc-client subsystem. JBoss Server Migration Tool performs the migration by default.

Additional resources

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

6.5.6. FIPS mode changes

Starting from JBoss EAP 7.1, automatic generation of a self-signed certificate is enabled by default for development purposes. If you are running in FIPS mode, configure the server to disable automatic self-signed certificate creation. Failure to do so may lead to the following error upon starting the server:

Copy to Clipboard Toggle word wrap 
ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

Additional resources

6.6. mod_cluster configuration changes

The configuration for static proxy lists in mod_cluster has changed in Red Hat JBoss Enterprise Application Platform 7.4.

Starting from JBoss EAP 7.4, the proxy-list attribute was deprecated and subsequently removed in JBoss EAP 8.0.

It has been replaced by the proxies attribute, which is a list of outbound socket binding names.

This change impacts how you define a static proxy list, for example, when disabling advertising for mod_cluster. For information about how to disable advertising for mod_cluster, see Disable advertising for mod_cluster in the JBoss EAP 7.4 Configuration Guide.

To ensure compatibility with JBoss EAP 8.0, update user scripts and legacy user CLI script as follows:

  • Replace the deprecated ssl=configuration with the appropriate elytron-based configuration.
  • Update the mod_cluster configuration path from /mod-cluster-config=CONFIGURATION to /proxy=default.
  • Update the dynamic load provider path in user scripts, replacing the deprecated path with provider=dynamic.
  • The deprecated connector attribute, which referred to an Undertow listener, has been removed. Update your user scripts to use the listener attribute as a replacement.

For more information about mod_cluster attributes, see ModCluster subsystem attributes in the JBoss EAP 7.4 Configuration Guide.

6.7. Viewing configuration changes

With Red Hat JBoss Enterprise Application Platform 7, you can track the configuration changes that were made to a running server. You can also view the history of configuration changes made by authorized users.

Whereas with JBoss EAP 7.0, you had to use the core-service management CLI command to configure options and to retrieve a list of recent configuration changes.

Example: List configuration changes in JBoss EAP 7.0

Copy to Clipboard Toggle word wrap 
/core-service=management/service=configuration-changes:add(max-history=10)
/core-service=management/service=configuration-changes:list-changes

JBoss EAP 7.1 introduced a new core-management subsystem that can be configured to track configuration changes made to the running server. This is the preferred method of configuring and viewing configuration changes in JBoss EAP 7.1 and later.

Example: List configuration changes in JBoss EAP 7.1 and later

Copy to Clipboard Toggle word wrap 
/subsystem=core-management/service=configuration-changes:add(max-history=20)
/subsystem=core-management/service=configuration-changes:list-changes

For more information about using the new core-management subsystem introduced in JBoss EAP 7.1, see View configuration changes in the JBoss EAP 7.4 Configuration Guide.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat, Inc.