Migration Guide from adnjboss to adnwildfly

This chapter provides a guideline for migrating a nevisIDM (v2.62 or newer) instance with container type adnjboss (v5.1.x) to a new nevisIDM instance with container type adnwildfly (v10.1.x). The chapter covers the most common configuration use cases and makes recommendations for their migration.

There is no automated instance migration. Gather the information from the current source adnjboss instance and use this information to create a new target adnwildfly instance.

If the current adnjboss instance and the new adnwildfly instance should be on the same host, the existing adnjboss instance must be stopped first: nevisidm <instance_name> stop

Adnjboss instance parameters gathering - Server parameters

In a first step, gather all the required parameters of the current adnjboss instance. See also the next table. Some parameters are only required in case TLS is used.

When all the required parameters are known, skip the step [Parameter retrieval].

Parameter	Default	Description
SERVER_URL_PROTOCOL	http or https	The server protocol, in case of TLS the protocol is https.
SERVER_URL_SERVER	localhost	The server host name
SERVER_URL_PORT	8989	The server port
PORT_RANGE_START	10000	To each service a port is assigned from this port range. The first service is the naming service of the application server. All other services are usually resolved via JNDI. An exception here is the web container port (used for web application and web service access). This one is specified using the SERVER_URL_PORT.
SERVER_SSL_KEYSTORE	/var/opt/neviskeybox/ default/default/node_keystore.jks	Keystore used to identify the server (sent to client on SSL/TLS client hello). Only required for TLS.
SERVER_SSL_KEYSTORE_PASSWORD		Passphrase to access the server keystore. Only required for TLS.
SERVER_SSL_TRUSTSTORE	/var/opt/neviskeybox/ default/default/truststore.jks	Truststore used to validate client certificates. Only required for TLS.
SERVER_SSL_TRUSTSTORE_PASSWORD		Passphrase to access the server truststore (usually not required, because truststore read for public certificates does not require protection). Only required for TLS.
NINJA_CERT	/var/opt/neviskeybox/ default/nevis/truststore.jks	This parameter is used to configure the trust anchor for Nevis SecToken validation. It is used by the Nevis JAAS login module.
RTOWNER	nvauser	Process owner of the instance
RTGROUP	nvbgroup	Process group of the instance

Parameter retrieval

The server parameters can be retrieved from different configuration files listed in the following subchapters.

server.xml

The parameters SERVER_URL_PROTOCOL, SERVER_URL_SERVER, SERVER_URL_PORT, SERVER_SSL_KEYSTORE and SERVER_SSL_KEYSTORE_PASSWORD can be read from the http/s connector element in the file server.xml. The file can be opened with the command nevisidm <instance_name> config server, or by opening the file /var/opt/nevisidm/<instance_name>/deploy/jbossweb.sar/server.xml.

Below see two examples of the protocol type httpsand http.

HTTPS connector server.xml

<Connector
 port="${SERVER_URL_PORT}" address="${SERVER_URL_SERVER}"
 maxThreads="200" minSpareThreads="4" maxSpareThreads="50"
 connectionTimeout="30000" acceptCount="200"
 maxKeepAliveRequests="100" maxHttpHeaderSize="8192" disableUploadTimeout="true"
 emptySessionPath="true" enableLookups="false" protocol="HTTP/1.1"
 SSLEnabled="true" secure="true" scheme="https" sslProtocol="TLSv1.2" ciphers="TLS_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA"
 keystoreFile="${SERVER_SSL_KEYSTORE}" keystoreType="JKS" keystorePass="${SERVER_SSL_KEYSTORE_PASSWORD}"
 clientAuth="false"
 SSLImplementation="ch.nevis.adnjboss.security.NevisJSSEImplementation"
/>

HTTP connector server.xml

<Connector
 port="${SERVER_URL_PORT}" address="${SERVER_URL_SERVER}"
 maxThreads="200" minSpareThreads="4" maxSpareThreads="50"
 connectionTimeout="30000" acceptCount="200"
 maxKeepAliveRequests="100" maxHttpHeaderSize="8192" disableUploadTimeout="true"
 emptySessionPath="true" enableLookups="false" protocol="HTTP/1.1"
/>

env.conf

The parameters PORT_RANGE_START, RTOWNER and RTGROUP can be read from the environment variable in the file env.conf. The file can be opened with the command nevisidm <instance_name> config env or by opening the file /var/opt/nevisidm/<instance_name>/conf/env.conf directly.

See example below:

JBOSS_PORT_RANGE_START=${PORT_RANGE_START}
RTOWNER=${RTOWNER}
RTGROUP=${RTGROUP}

The parameters RTOWNER and RTGROUP should be consistent with the owner and the group of the instance in the file system, i.e.:

> ls -ld /var/opt/nevisidm/<instance_name> | awk '{print $3}'
${RTOWNER}
> ls -ld /var/opt/nevisidm/<instance_name> | awk '{print $4}'
nvbgroup
${RTGROUP}

batchjob-config-reloader.properties

The parameters SERVER_SSL_TRUSTSTORE and SERVER_SSL_TRUSTSTORE_PASSWORD can be read from the batch job configuration in the file batchjob-config-reloader.properties. The file can be opened at /var/opt/nevisidm/<instance_name>/conf/batchjob-config-reloader.properties directly.

See example below:

SERVER_SSL_TRUSTSTORE=${SERVER_SSL_TRUSTSTORE}
SERVER_SSL_TRUSTSTORE_PASSWORD=${SERVER_SSL_TRUSTSTORE_PASSWORD}

login-config.xml

The parameter NINJA_CERT can be read from the Ninja setup in the file login-config.xml. The file can be opened with the command nevisidm <instance_name> config login or by opening the file /var/opt/nevisidm/<instance_name>/conf/login-config.xml directly.

See example below:

<!-- BEGIN NINJA SETUP -->
<!--
To use nevis security for all applications, replace 'NevisSecTokenDomain' with 'other' and
disable the existing 'other' policy or rename it e.g. to the 'web-console' if you want to
use the existing properties based user registry for this purpose.
NOTE: adnjboss admin command renames 'NevisSecTokenDomain' to 'other' if SERVER_PROFILE=auth_ninja is used.
-->
<application-policy name = "other">
 <authentication>
 <login-module code="ch.nevis.ninja.jboss.loginmodule.SecTokenLoginModule" flag="required">
 <!-- mandatory parameter 'signerCert':
 name (and path) of signer certificate (pem or der format).
 -->
 <module-option name="NevisSignerCertificate">${NINJA_CERT}</module-option>

 <!-- optional parameter 'debug':
 set to true to turn on verbose logging
 (Logger base name: 'ch.nevis.ninja.jboss')
 -->
 <module-option name="LogDebug">false</module-option>

 <!-- Default is StaticRoleGetter(roles="member") which sets a single
 role named "member". To use the roles from the token, use
 "TokenRoleGetter". To customize the process of finding the roles
 for a given user, the LoginModule has its own little plug-in
 mechanism: Just Implement the service provider interface
 ch.nevis.ninja.commons.mapping.RoleGetter and register the full
 class name of your implementation with the RoleGetter option.
 Your class must have a constructor taking a HashMap as only
 argument. To pass values to your constructor, use name/value pairs.
 Example: com.foo.bar.MyRoleGetter(name="value1", name2="value2")
 -->
 <module-option name="RoleGetters">TokenRoleGetter</module-option>

 <!-- This option specifies the User Getter, default is TokenUserGetter
 which takes the user from the token. To customize the User Getter,
 implement the interface ch.nevis.ninja.commons.mapping.UserGetter.
 The constructor takes a single HashMap.
 -->
 <module-option name="RoleGetters">ch.nevis.ninja.commons.mapping.StaticRoleGetter, ch.nevis.ninja.commons.mapping.TokenRoleGetter</module-option> <!-- PATCH LINE -->
 </login-module>
 </authentication>
</application-policy>
<!-- END NINJA SETUP -->

Adnwildfly instance creation

A new instance with container type adnwildfly and the desired parameters has to be created with the following command:

nevisidm inst create <new_instance_name> IDM_DEPLOY_TYPE=adnwildfly \
 IDM_APPL_URL=<server_url_protocol>://<server_url_server>:<server_url_port>
 PORT_RANGE_START=<port_range_start> \
 SERVER_SSL_KEYSTORE=<server_ssl_keystore> \
 SERVER_SSL_KEYSTORE_PASSWORD=<server_ssl_keystore_password> \
 SERVER_SSL_TRUSTSTORE=<server_ssl_truststore> \
 SERVER_SSL_TRUSTSTORE_PASSWORD=<server_ssl_truststore-password> \
 NINJA_CERT=<ninja_cert> \
 RTOWNER=<rtowner> \
 RTUSER=<rtgroup>

Adnwildfly configuration check

Standalone.xml

The adnwildfly instance has only one file for server and login configurations, the standalone.xml. The standalone.xml can be opened with the command nevisidm config server. Alternatively, the file can be opened directly at /var/opt/adnwildfly/instances/<new_instance_name>/standalone/configuration/standalone.xml. Below see the excerpts containing the corresponding configurations for https and https.

There are no connector settings in adnwildfly. The connectivity settings are located in security realms and corresponding http/s-listeners/socket-bindings. Additionally, the SecToken login-module is configured in the security subsystem.

HTTPS standalone.xml

<security-realms>
 <security-realm name="SslRealm">
 <server-identities>
 <ssl>
 <keystore path="${SERVER_SSL_KEYSTORE}" keystore-password="${SERVER_SSL_KEYSTORE_PASSWORD}"/>
 </ssl>
 </server-identities>
 <authentication>
 <truststore path="${SERVER_SSL_TRUSTSTORE}" keystore-password="${SERVER_SSL_TRUSTSTORE_PASSWORD}"/>
 </authentication>
 </security-realm>
</security-realms>

<profile>
 <subsystem xmlns="urn:jboss:domain:undertow:1.2">
  <buffer-cache name="default" />
  <server name="default-server">
   `<http-listener name="default-ssl" socket-binding="https" security-realm="SslRealm"/>
   <host name="default-host" alias="${SERVER_URL_SERVER}"/>
  </server>
  <servlet-container name="default">
   <jsp-config />
  </servlet-container>
 </subsystem>
 <subsystem xmlns="urn:jboss:domain:security:1.2">
 <security-domains>
 <security-domain name="NevisSecTokenDomain" cache-type="default">
 <authentication>
 <login-module code="ch.nevis.ninja.jboss.auth.NinjaJbossLoginModuleImpl" flag="required" module="ch.nevis.ninja">
 <module-option name="NevisSignerCertificate" value="${NINJA_CERT}"/>
 <module-option name="UserGetter" value="AttributeUserGetter(source=loginId)"/>
 <module-option name="AdjustIdentity" value="true"/>
 <module-option name="LogDebug" value="false"/>
 <module-option name="RoleGetters" value="ch.nevis.ninja.commons.mapping.StaticRoleGetter, ch.nevis.ninja.commons.mapping.TokenRoleGetter"/>
 </login-module>
 </authentication>
 </security-domain>
 </security-domains>
 </subsystem>
</profile>

<interfaces>
 <interface name="public">
 <inet-address value="${SERVER_URL_SERVER}"/>
 </interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
 <socket-binding name="https" port="${SERVER_PORT}" fixed-port="true" />
</socket-binding-group>

HTTP standalone.xml

<profile>
 <subsystem xmlns="urn:jboss:domain:undertow:1.2">
  <buffer-cache name="default"/>
  <server name="default-server">
   <http-listener name="default" socket-binding="http" redirect-socket="http"/>
   <host name="default-host" alias="${SERVER_URL_SERVER}"/>
  </server>
  <servlet-container name="default">
  <jsp-config/>
  </servlet-container>
 </subsystem>
 <subsystem xmlns="urn:jboss:domain:security:1.2">
 <security-domains>
 <security-domain name="NevisSecTokenDomain" cache-type="default">
 <authentication>
 <login-module code="ch.nevis.ninja.jboss.auth.NinjaJbossLoginModuleImpl" flag="required" module="ch.nevis.ninja">
 <module-option name="NevisSignerCertificate" value="${NINJA_CERT}"/>
 <module-option name="UserGetter" value="AttributeUserGetter(source=loginId)"/>
 <module-option name="AdjustIdentity" value="true"/>
 <module-option name="LogDebug" value="false"/>
 <module-option name="RoleGetters" value="ch.nevis.ninja.commons.mapping.StaticRoleGetter, ch.nevis.ninja.commons.mapping.TokenRoleGetter"/>
 </login-module>
 </authentication>
 </security-domain>
 </security-domains>
 </subsystem>
</profile>

<interfaces>
 <interface name="public">
  <inet-address value="${SERVER_URL_SERVER}"/>
 </interface>
</interfaces>

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
 <socket-binding name="http" port="${SERVER_PORT}" fixed-port="true"/>
</socket-binding-group>

The parameter PORT_RANGE_START is added to the file vmargs.conf. The vmargs.conf can be opened with the command nevisidm config vmargs. Alternatively, the file can be opened directly at /var/opt/nevisidm/<new_instance_name>/conf/vmargs.conf.

vmargs.conf

-Djboss.socket.binding.port-offset=${PORT_RANGE_START}

Instance configuration migration

Copy configurations

The following configuration files can be copied from the adnjboss instance directly to the adnwildfly instance.

cp -f /var/opt/nevisidm/<instance_name>/conf/attrAccess.properties /var/opt/nevisidm/<new_instance_name>/conf/attrAccess.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/authorizationConfig.properties /var/opt/nevisidm/<new_instance_name>/conf/authorizationConfig.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/batchjob-config-reloader.properties /var/opt/nevisidm/<new_instance_name>/conf/batchjob-config-reloader.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/dataSource.xml /var/opt/nevisidm/<new_instance_name>/conf/dataSource.xml
cp -f /var/opt/nevisidm/<instance_name>/conf/rolesAssignment.properties /var/opt/nevisidm/<new_instance_name>/conf/rolesAssignment.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/rolesMapping.properties /var/opt/nevisidm/<new_instance_name>/conf/rolesMapping.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/roles.properties /var/opt/nevisidm/<new_instance_name>/conf/roles.properties
cp -f /var/opt/nevisidm/<instance_name>/conf/tlds-alpha-by-domain.txt /var/opt/nevisidm/<new_instance_name>/conf/tlds-alpha-by-domain.txt
cp -f /var/opt/nevisidm/<instance_name>/conf/transactionAOP.xml /var/opt/nevisidm/<new_instance_name>/conf/transactionAOP.xml

Migrate configurations

The following files of the adnjboss instance contain instance name-specific path configurations and hence cannot be copied. I.e., every custom configuration different from the default value shall be manually migrated and adjusted/set in the corresponding new generated files of the adnwildfly instance. It is recommended to use a diff tool like Meld (http://meldmerge.org/) to compare the two versions.

/var/opt/nevisidm/<instance_name>/conf/nevisidm-prod.properties to /var/opt/nevisidm/<new_instance_name>/conf/nevisidm-prod.properties
/var/opt/nevisidm/<instance_name>/conf/vmargs.conf to /var/opt/nevisidm/<new_instance_name>/conf/vmargs.conf

Special configurations

Client certificate authentication

If two-way TLS client certificate authentication is used in the current adnjboss instance, an additional connector and login module must be migrated to the new adnwildfly instance.

Client certificate parameters

In a first step all the required parameters of the current adnjboss instance shall be gathered. If all the required parameters are known, the next step should be skipped and it can be continued directly with Client certificate configuration.

It may be that these parameters, except of the CC_SERVER_URL_PORT, have the same values as the parameters of the server parameter table in Server parameters.

Parameter	Default	Description
CC_SERVER_URL_SERVER	localhost	The server host name used for client certificate authentication
CC_SERVER_URL_PORT	8443	The server port used for client certificate authentication
CC_SERVER_SSL_KEYSTORE	/var/opt/neviskeybox/ default/default/node_keystore.jks	Keystore used to identify the server for client certificate authentication
CC_SERVER_SSL_KEYSTORE_PASSWORD		Passphrase to access the server keystore used for client certificate authentication
CC_SERVER_SSL_TRUSTSTORE	/var/opt/neviskeybox/ default/default/truststore.jks	Truststore used to validate client certificates for client certificate authentication
CC_SERVER_SSL_TRUSTSTORE_PASSWORD		Passphrase to access the server truststore for client certificate authentication (usually not required, because truststore read for public certificates does not require protection)

Parameter retrieval

The client certificate parameters can be retrieved from the corresponding http/s connector element in the file server.xml. The file can be opened with the command nevisidm <instance_name> config server or by opening the file /var/opt/nevisidm/<instance_name>/deploy/jbossweb.sar/server.xml directly. Below see excerpt containing the configurations:

HTTPS connector client certificate authentication server.xml

<Connector protocol="HTTP/1.1" SSLEnabled="true"
 port="${CC_SERVER_URL_PORT}" address="${CC_SERVER_URL_SERVER}"
 scheme="https" secure="true" clientAuth="true"
 keystoreFile="${CC_SERVER_SSL_KEYSTORE}"
 keystorePass="${CC_SERVER_SSL_KEYSTORE_PASSWORD}"
 truststoreFile="${CC_SERVER_SSL_TRUSTSTORE}"
   truststorePass="${CC_SERVER_SSL_TRUSTSTORE_PASSWORD}"
 sslProtocol = "TLS" />

Client certificate configuration

For client certificate authentication a new security-realm, https-listener, socket-binding and a new login-module should be added to the existing elements in the standalone.xml. The standalone.xml can be opened with the command nevisidm config server. Alternatively, the file can be opened directly at /var/opt/adnwildfly/instances/<new_instance_name>/standalone/configuration/standalone.xml. Below see the excerpts containing the corresponding configurations, which should be added.

Client certificate authentication standalone.xml

<security-realms>
 <security-realm name="CcSslRealm">
 <server-identities>
 <ssl>
 <keystore path="${CC_SERVER_SSL_KEYSTORE}" keystore-password="${CC_SERVER_SSL_KEYSTORE_PASSWORD}"/>
 </ssl>
 </server-identities>
 <authentication>
 <truststore path="${CC_SERVER_SSL_TRUSTSTORE}" keystore-password="${CC_SERVER_SSL_TRUSTSTORE_PASSWORD}"/>
 </authentication>
 </security-realm>
</security-realms>

<profile>
 <subsystem xmlns="urn:jboss:domain:undertow:1.2">
  <buffer-cache name="default" />
  <server name="default-server">
   `<http-listener name="cc-ssl" socket-binding="cc-https" security-realm="CcSslRealm" verify-client="required"/>
   <host name="default-host" alias="${CC_SERVER_URL_SERVER}"/>
  </server>
  <servlet-container name="default">
   <jsp-config />
  </servlet-container>
 </subsystem>
 <subsystem xmlns="urn:jboss:domain:security:1.2">
 <security-domains>
  <security-domain name="NevisIDMClientCertDomain" cache-type="default">
   <authentication>
   <login-module code="ch.adnovum.nevisidm.jaas.CertLoginModule" flag="required" module="ch.nevis.ninja">
   <!-- <module-option name="Debug">true</module-option> -->
 </login-module>
 </authentication>
 </security-domain>
 </security-domains>
 </subsystem>
</profile>

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
 <socket-binding name="cc-https" port="${CC_SERVER_URL_PORT}" fixed-port="true"/>
</socket-binding-group>

If not yet migrated in Migrate Configurations, the following two configurations should be added to the file vmargs.conf. The vmargs.conf can be opened with the command nevisidm config vmargs. Alternatively, the file can be opened directly at /var/opt/nevisidm/<new_instance_name>/conf/vmargs.conf.

Client certificate authentication vmargs.conf

-Dch.adnovum.nevisidm.web.servlets.ForwardServlet.Enabled=true
-Dch.adnovum.nevisidm.web.servlets.ForwardServlet.ForwardPath=/services/

JMS

The JBoss Messaging (which is used in adnjboss) is no longer included in adnwildfly. The JMS server configuration in adnwildfly is done through the messaging-activemq subsystem. (see: https://docs.jboss.org/author/display/WFLY10/Messaging%20configuration.html).

In adnwildfly, the JMS doesn’t need a dedicated database at all but only configuration of a new subsystem for activemqin the standalone.xml. The standalone.xml can be opened with the commands nevisidm config serveror nevisidm config login. Alternatively, the file can be opened directly at /var/opt/adnwildfly/instances/<new_instance_name>/standalone/configuration/standalone.xml. Below see the excerpts containing the corresponding JMS configurations for https and https.

JMS HTTPS standalone.xml

<profile>
  <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
 <server name="default">
 <security-setting name="#">
 <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
 </security-setting>
 <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
 <http-connector name="http-connector" socket-binding="https" endpoint="http-acceptor">
  <param name="ssl-enabled" value="true" />
 </http-connector>
 <http-connector name="http-connector-throughput" socket-binding="https" endpoint="http-acceptor-throughput">
  <param name="ssl-enabled" value="true" />
 <param name="batch-delay" value="50"/>
 </http-connector>
 <in-vm-connector name="in-vm" server-id="0"/>
 <http-acceptor name="http-acceptor" http-listener="default"/>
 <http-acceptor name="http-acceptor-throughput" http-listener="default">
 <param name="batch-delay" value="50"/>
 <param name="direct-deliver" value="false"/>
 </http-acceptor>
 <in-vm-acceptor name="in-vm" server-id="0"/>
 <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
 <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
 <jms-queue name="java:jboss/exported/jms/queue/Provisioning" entries="java:jboss/exported/jms/queue/Provisioning"/>
 <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
 <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
 <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
 </server>
 </subsystem>
</profile>

JMS HTTP standalone.xml

<profile>
  <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
 <server name="default">
 <security-setting name="#">
 <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
 </security-setting>
 <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
 <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
 <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
 <param name="batch-delay" value="50"/>
 </http-connector>
 <in-vm-connector name="in-vm" server-id="0"/>
 <http-acceptor name="http-acceptor" http-listener="default"/>
 <http-acceptor name="http-acceptor-throughput" http-listener="default">
 <param name="batch-delay" value="50"/>
 <param name="direct-deliver" value="false"/>
 </http-acceptor>
 <in-vm-acceptor name="in-vm" server-id="0"/>
 <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
 <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
 <jms-queue name="java:jboss/exported/jms/queue/Provisioning" entries="java:jboss/exported/jms/queue/Provisioning"/>
 <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
 <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
 <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
 </server>
 </subsystem>
</profile>

Adnwildfly instance start

After the migration is completed, the new adnwildfly instance can be started with the following command:

nevisidm <new_instance_name> start

Adnjboss instance removal

After the new adnwildfly instance is successfully migrated, the old adnjboss instance can be removed with the following command:

nevisidm inst remove <instance_name>