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. /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. /subsystem=undertow/server=default-server/host=default-host/location=\/:remove /subsystem=undertow/configuration=handler/file=welcome-content:remove reload Additional resources Configure the Default Welcome Web Application 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. <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="USD{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. <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="USD{jboss.home.dir}/welcome-content"/> </handlers> </subsystem> The following is an example of the default undertow subsystem configuration in JBoss EAP 8.0. <subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="USD{wildfly.undertow.statistics-enabled:USD{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="USD{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. /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. 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 resources New non-distributable SFSB cache New 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: Preferred JBoss EAP 8.0 configuration: 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 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. /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 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 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 release to an XML file, and then import that file using the import-journal operation: Export messaging data from JBoss EAP 7.x. release 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 Open a terminal, navigate to the JBoss EAP 7.x install directory, and start the server in admin-only mode. USD EAP_HOME/bin/standalone.sh -c standalone-full.xml --start-mode=admin-only Open a new terminal, navigate to the JBoss EAP 7.x install directory, and connect to the management CLI. USD EAP_HOME/bin/jboss-cli.sh --connect Use the following management CLI command to export the messaging journal data. /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 . 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. Open a new terminal, navigate to the JBoss EAP 8.0 install directory, and connect to the management CLI. Use the following management CLI command to import the messaging data: 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 Shut down the JBoss EAP 8.0 server. 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. 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. 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: Configuring JBoss EAP 8.0 server 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 Create the following jms-queue configuration for the default server in the messaging-activemq subsystem of the JBoss EAP 8.0 server. jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue] Make sure that messaging-activemq subsystem default server contains a configuration for the InVmConnectionFactory connection-factory similar to the following: <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: /subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory]) 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. /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. <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 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. Make sure that you have deployed the target Jakarta Messaging destination to the JBoss EAP 8.0 server. 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 Determine the location of your messaging data by using the following management CLI commands: /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. 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. /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 . /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 Migrating to Elytron 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 Migrate secure vaults and properties Credentials and credential stores in Elytron 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 Migrate Authentication Configuration Migrate Database Authentication Configuration to Elytron Migrate Composite Stores to Elytron Migrate Security Domains That Use Caching to Elytron Migrating Legacy Properties-based Configuration to Elytron Migrating LDAP Authentication Configuration to Elytron Migrate Kerberos Authentication to Elytron Migrate SSL Configurations Securing applications and management interfaces using an identity store Securing applications and management interfaces using multiple identity stores 6.5.3. PicketLink subsystem removal The PicketLink subsystem has been removed from JBoss EAP 8.0. Use Red Hat build of Keycloak instead of the PicketLink identity provider, and the Red Hat build of Keycloak SAML adapter instead of the PicketLink service provider. Additional resources PicketLink removal Red Hat build of Keycloak 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 Migrate keycloak subsystem OpenID Connect configuration in JBoss EAP 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 JAAS realm in the elytron subsystem 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: 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 Enabling SSL/TLS for applications by using the automatically generated self-signed certificate 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 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 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 .

Commands:
/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)
/subsystem=undertow/server=default-server/host=default-host/location=\/:remove /subsystem=undertow/configuration=handler/file=welcome-content:remove reload
<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="USD{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>
<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="USD{jboss.home.dir}/welcome-content"/> </handlers> </subsystem>
<subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="USD{wildfly.undertow.statistics-enabled:USD{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="USD{jboss.home.dir}/welcome-content"/> </handlers> <application-security-domains> <application-security-domain name="other" security-domain="ApplicationDomain"/> </application-security-domains> </subsystem>
/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)
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
/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)
/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)
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
/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])
EAP_HOME/bin/standalone.sh -c standalone-full.xml --start-mode=admin-only
EAP_HOME/bin/jboss-cli.sh --connect
/subsystem=messaging-activemq/server=default:export-journal()
EAP_HOME /bin/jboss-cli.sh --connect
/subsystem=messaging-activemq/server=default:import-journal(file= OUTPUT_DIRECTORY /OldMessagingData.xml)
jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]
<connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>
/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])
/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)
<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>
/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
/subsystem=messaging-activemq/server=default/ha-policy=replication-primary:add(cluster-name=my-cluster,group-name=group1)
/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"} }
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
/core-service=management/service=configuration-changes:add(max-history=10) /core-service=management/service=configuration-changes:list-changes
/subsystem=core-management/service=configuration-changes:add(max-history=20) /subsystem=core-management/service=configuration-changes:list-changes