Support for JBoss EAP 7.2 and WildFly 15.0.x

cim143
This page contains the following topics:
2
Overview
The migration process described in this topic is for instances of Identity Suite deployed to JBoss EAP 6.4 or WildFly 8.2, and now need to deploy to JBoss EAP 7.2 or WildFly 15.0.1. Support for new deployments of the Identity Suite servers to JBoss EAP 7.2 and/or WildFly 15 will be provided in a future release of Identity Suite. Support for Identity Suite Virtual Appliance using WildFly 15.0.1 will also be made available in a future release.Versions 14.2 and 14.3 of Identity Suite now support running Identity Portal, Identity Governance, and Identity Manager in JBoss 7.2 GA and WildFly 15.0.1. Red Hat and WildFly.org have provided a "lift and shift" upgrade strategy to these versions. This strategy uses the Red Hat JBoss Application Migration Toolkit and the JBoss Server Migration Tool. These tools work on both JBoss EAP and WildFly servers.
The JBoss EAP 7.2 Migration Guide provides full details on the migration strategy and process for your reference. Identity Suite completed the migration analysis as outlined in the Migration Analysis Toolkit. The results show that the three Identity Suite Servers passed the criteria for Migration based on the deployment configurations supported by the Identity Suite installers. To enhance the migration experience, Identity Suite provides a wrapper script that executes both pre- and post-Server Migration tool changes and validations. This script, called the Layer 7 JBoss Migration script, performs the following functions:
  1. Validates the source and destination Server versions supported by Identity Suite
  2. Adjusts certain configuration parameters to those supported by EAP 7.2 and WildFly 15.0.1, prior to invoking the Server Migration tool.
  3. Invokes the Server Migration Tool from Red Hat and WildFly.org.
  4. Performs post-migration tool steps and additional verifications.
If you migrate to the supported version of the JBoss/WildFly application server for Identity Manager 14.2, you can not upgrade from Identity Manger version 14.2 to 14.3.
Migrating Identity Manager Servers
This page describes the process for migrating Identity Manager Servers.
Identity Manager Migration Prerequisites
Before running the migration tool, ensure that the following pre-requisites are met on each of the nodes.
  1. Apply the latest Identity Manager Cumulative Patch including the WorkPoint Tools patch.
  2. Install JBoss EAP 7.2 or WildFly 15.0.1 on the existing Identity Manager server.
  3. Click here download the Layer7 Migration Tool, and then extract it.
  4. For WildFly 15, click here to download the v1.5.x binary distribution of the JBoss Server Migration Tool from the JBoss Server Migration Tool GitHub repository. For JBoss EAP 7.2 GA, the tool is already part of the GA distribution installed in Step 2.
  5. Ensure that the continuous import and export operations between Identity Manager and Identity Governance are stopped and the JMS queues are empty.
  6. Update the JBOSS_HOME environment variable to match the new JBoss/WildFly destination folder.
The Migration tool does not migrate JMS message data. For Identity Manager, all Identity Manager Admin Tasks need to be in a state that does not depend on an Event message to continue processing. These states include: Pending Workflow Approval, Completed, Failed, Partially Completed, Scheduled, and Cancelled. All other Identity Manager Tasks that are in progress rely on JMS messages in the Identity Manager Event Queue for continued processing will not be migrated. Those tasks will need to be resubmitted after migration.
The patch contains the following files:
  • Layer7_migrate_tool.sh
  • Layer7_migrate_tool.bat
  • Layer7_migrate_im_environment.properties
  • Layer7_migrate_ig_environment.properties
  • Layer7_migrate_ip_sqlserver_environment.properties
  • Layer7_migrate_ip_oracle_environment.properties
Starting with an existing node with either EAP 6.4.X or WildFly 8.2, use the following graphic details for the entire migration procedure:
Release Upgrade Support
Run the Migration Tool
Run the migration tool on each of the nodes by following the given steps:
  1. Stop the Identity Manager Application server on all the nodes.
  2. From the command line, navigate to the location where you had downloaded and extracted the Layer7 Migration Tool.
  3. Depending on operating system, run the migration tool with the following arguments:  Running it without any parameters will provide you with command line help.
    • Windows:
      Layer7_migrate_tool.bat-s [source-dir] -t [output-dir]
    • Linux:
      Usage: Layer7_migrate_tool.sh -s [source-dir] -t [output-dir]
      [source-dir]
      is the source application server and [
      output-dir]
      is the target application server in the following steps.
      Note:
      There are two points to this note regarding
      custom modules
      and
      custom data drivers
      :
      A)
      Custom modules
      : The Layer7 migration scripts handles all the dependency modules present in the <Application Server>/modules folder installed and configured by the CA Identity Manager Installation. If you have any other custom modules configured apart from the defaults, include them in Layer7_migrate_im_environment.properties file. Default content in this file appears as follows:
      ############################################### ### Layer7 Migration Environment ### ############################################### # Please refer to user guide for these properties specification # ####### TASKS domain.skip=false standalone.skip=false ### If set any deployment found is not migrated in non-interactive mode deployments.migrate-deployments.skip=false ### If set any persistent deployment found is not migrated in non-interactive mode deployments.migrate-persistent-deployments.skip=false ### If set any deployment found in a directory watched by a deployment scanner, is not migrated in non-interactive mode deployments.migrate-deployment-scanner-deployments.skip=false # a list with module names to migrate modules.includes=com.ca.iam.crypto,com.ca.iam.bouncy, com.ca.iam.idmutils,com.ca.iam.nim,com.ca.iam.cajasper subsystem.logging.update.remove-console-handler.skip=false subsystem.undertow.update.add-undertow-https-listener.skip=true
      For example: If the existing JBoss EAP 6.4.X has a custom module configured in the custom/org/test/ directory,include this custom module (custom.org.test) for migration in the
      modules.include
      property, so the
      modules.include
      property file appears like the following example:
      ############################################### ### Layer7 Migration Environment ### ############################################### # Please refer to user guide for these properties specification # ####### TASKS domain.skip=false standalone.skip=false ### If set any deployment found is not migrated in non-interactive mode deployments.migrate-deployments.skip=false ### If set any persistent deployment found is not migrated in non-interactive mode deployments.migrate-persistent-deployments.skip=false ### If set any deployment found in a directory watched by a deployment scanner, is not migrated in non-interactive mode deployments.migrate-deployment-scanner-deployments.skip=false # a list with module names to migrate modules.includes=com.ca.iam.crypto,com.ca.iam.bouncy,com.ca.iam.idmutils, com.ca.iam.nim,com.ca.iam.cajasper,custom.org.test subsystem.logging.update.remove-console-handler.skip=false subsystem.undertow.update.add-undertow-https-listener.skip=true
      B)
      Custom data drivers
      : If custom data drivers were added to the <Application Server>/modules/com/ca/iam/jdbc/ folder, treat them as custom modules and include them in the
      modules.include
      property as mentioned in point (a), using the full name as com.ca.iam.jdbc.<custom_data_driver>:
      • For
        Linux
        , run
        Layer7_migrate_tool.sh
        with the following arguments:
        Layer7_migrate_tool.sh -s “<
        Location where the existing EAP 6.4 or WildFly 8 application server is installed
        >” -t “<
        Location where the latest EAP 7.2 or WildFly 15 application server is installed
        >”
        For
        Windows
        , run
        Layer7_migrate_tool.bat
        with the following arguments:
        C:\Layer7MigrationTool>Layer7_migrate_tool.bat -s “<
        Location where the existing EAP 6.4 or WildFly 8 application server is installed
        >” -t “<
        Location where the latest EAP 7.2 or WildFly 15 application server is installed
        >”
        If the folder name in the application server path contains spaces, add the short name path of that folder name to the tool. The short name on Windows can be retrieved using the
        dir /x
        command. For example, the short name path for “Program Files” is PROGRA~1. For example:
        C:\jbossMigration>Layer7_migrate_tool.bat -s “C:\
        PROGRA~1
        \IM\Server\jboss-6.4” -t “C:\jboss-7.2”
      Note
      : For the WildFly migration from 8.2.X to WildFly 15.0.1, the Layer7 Migration script prompts for the location of the Native. When prompted to enter the
      Absolute Path of the Native Migration tool
      , enter the path where the
      jboss-server-migration.<sh>/<bat>
      file resides.
      When prompted, enter this absolute path.
  4. The Layer7 migration script proceeds with pre-migration, invoking the Native migration tool. The
    Migration Result: SUCCESS
    message appears when these two steps successful complete. The
    Press any key to continue…
    message appears. Press the
    Enter
    key to proceed with Post migration step.
If the migration fails, the migration utility exits without any prompt, and then proceeds with post migration steps. Refer to the
migration.log
stored in the Native tool migration folder under logs/ folder for more information of why the migration might have failed.
If the migration fails and if you plan to reattempt the migration, completely remove the migrated folder (that is, EAP 7.2 or WildFly 15.0.1) and re-install/extract the target application servers (EAP 7.2 and WildFly 15.0.1) again before retrying. Once the post migration step completes, the Layer7 migration script exits.
Scenario-Specific Manual Steps
Perform the steps that correspond with the following deployments scenarios.
SSL configured on the Source Application Server
  • The Native Migration tool handles the SSL configuration migration when migrating from JBoss EAP 6.4.X to EAP 7.2 along with keystore file.  If the keystore is placed inside the ~/EAP6.4.X/standalone/configuration/ folder and mentioned in the configuration xml using the JBoss property jboss.server.config.dir, then the Native migration tool handles the file copy to the target application server (that is, the EAP 7.2 configuration folder) found here: ~/jboss 7.2/standalone/configuration/
  • The Native Migration tool handles the SSL configuration migration when migrating from WildFly 8.2.X to WildFly 15.0.1 but
    does not
    migrate the keystore file, if the keystore is placed inside the
    ~/wildfly8.2.X/standalone/configuration/
    folder and mentioned in the configuration xml using the property jboss.server.config.dir.
Manually copy this file to the target application server configuration folder:
~/wildfly15.0.1/standalone/configuration/
XML Style Comments in a Custom JSP
Multiline XML style comments in JSP is not supported in EAP 7.2 and WildFly 15.0.1, please remove such commented lines from any custom JSP. The Layer7 migration script handles one such case for NIM integration JSP installed by the CA Identity Manager.  The tool doesn’t handle any other cases.
Application Startup Configured as Service
If the application server startup was configured as a service, then the Layer7 migration script does not reconfigure the service with the target application server after migration. You must update the service manually.For more information, see these topics:
Migration of JBoss EAP 6.4 to 7.2 on Identity Manager Unicast Cluster
  1. Navigate to
    <JBoss/WildFly_Home>/standalone/configuration
    .
  2. Open
    standalone-full-ha-ca-gm.xml
    file for editing.
  3. In the subsystem element of type
    jgroups
    (<subsystem xmlns="urn:jboss:domain:jgroups:6.0">), do the following edits.
    1. In the
      transport
      element of type
      TCP
      and
      UDP
      , add the following property in case you want to avoid discarded messages:
      <property name="log_discard_msgs">false</property>
      Sample code snippet after adding the property:
      <stack name="tcp"> <transport type="TCP" socket-binding="jgroups-tcp"> <property name="port_range">50</property> <property name="log_discard_msgs">false</property> </transport> .... </stack> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"> <property name="port_range">50</property> <property name="log_discard_msgs">false</property> </transport> .... </stack>
    2. In the protocol element of type
      org.jgroups.protocols.TCPPING
      , do the following edits.
      1. Change FNQ name in the protocol type from
        org.jgroups.protocols.TCPPING
        to
        TCPPING
        .
      2. Remove the following two properties:
        • <property name="num_initial_members">
        • <property name="timeout">
      Sample code snippet after the edits:
      <protocol type="TCPPING" module="org.jgroups"> <property name="initial_hosts">host1,host2</property> <property name="port_range">1</property> </protocol>
    3. In the protocol element of type pbcast.GMS, add join_timeout property with the same timeout value that you had configured in the pre-migration setup. This property is a replacement for the timeout property that we had removed in step b.
    <protocol type="pbcast.GMS" module="org.jgroups"> <property name="join_timeout">50000</property> </protocol>
Configure WorkPoint Administrative Tool on JBoss or WildFly
To configure the WorkPoint Administrative Tools, edit the
init.bat/sh
and the
workpoint-client.properties
files as required on JBoss EAP 7.2 and WildFly 15.0.1.
Edit init.bat/init.sh
Use the following procedure to the edit init.bat/init.sh files:
  1. In a text editor, edit one of the following files:
    • Windows:
      admin_tools
      \WorkPoint\bin\init.bat
    • UNIX:
      admin_tools/
      WorkPoint/bin/init.sh
  2. Locate the JBoss section of the init.bat or init.sh that matches your version of JBoss 7 or WildFly 15.0.1.
  3. Un-comment EJB_CLASSPATH if commented.
Note:
Be sure that all sections for other application servers are commented.Two options are available to configure the required jars:
Option-1:
For Windows:
SET JBOSS_HOME=<Set the JBoss Server Home>
SET EJB_CLASSPATH=%JBOSS_HOME%\bin\client\jboss-client.jar;%JBOSS_HOME%\modules\org\jboss\as\naming\main\jboss-as-naming-7.1.1.Final.jar;% JBOSS_HOME%\modules\org\JBoss\msc\main\jboss-msc-1.0.2.GA.jar;%JBOSS_HOME%\jboss-modules.jar
For Linux:
JBOSS_HOME=<Set the JBoss Server Home>
EJB_CLASSPATH=$ JBOSS_HOME/bin/client/jboss-client.jar:$JBOSS_HOME/modules/org/JBoss/as/naming/main/jboss-as-naming-7.1.1.Final.jar:$JBOSS_HOME/modules/org/jboss/msc/main/jboss-msc-1.0.2.GA.jar:$JBOSS_HOME/jboss-modules.jar
Option-2:
Copy the following four JAR files to
admin_tools
\WorkPoint\lib\:
  • <appserver_home>\bin\client\
    jboss-client.jar
  • <appserver_home>\modules\system\layers\base\org\jboss\as\naming\main
    \wildfly-naming-
    <version>
    .jar
  • <appserver_home>\modules\system\layers\base\org\JBoss\msc\main\
    jboss-msc-
    <version>
    .jar
  • <appserver_home>\
    jboss-modules.jar
Edit the EJBCLASSPATH to reflect this by using the relative path in the jar location, as shown in the following example:
For Windows
:
  • SET
    EJB_CLASSPATH=
    ../lib/
    JBoss-client.jar:
    ../lib/
    JBoss-as-naming-7.5.0.Final-redhat-21.jar:
    ../lib/
    JBoss-msc-1.1.5.Final-redhat-1.jar:
    ../lib/
    JBoss-modules.jar
For Linux:
  • EJB_CLASSPATH=
    ../lib/
    jboss-client.jar:
    ../lib/
    jboss-as-naming-7.5.0.Final-redhat-21.jar:
    ../lib/
    jboss-msc-1.1.5.Final-redhat-1.jar:
    ../lib/
    jboss-modules.jar 
4. Edit JAVADPARAMS to include the WorkPoint client properties file location after the EJB_CLASSPATH as shown in the following examples:
For Windows:
SET JAVADPARMS=%JAVADPARMS% -DJBoss.ejb.client.properties.file.path=../conf/workpoint-client.properties
For Linux:
JAVADPARMS=$JAVADPARMS" -Djboss.ejb.client.properties.file.path=../conf/workpoint-client.properties"
Edit workpoint-client.properties
Edit the
workpoint-client.properties
file based on the type of application server you selected during the Identity Manager installation.
To configure the workpoint-client.properties file:
  1. Open
    admin_tools
    \WorkPoint\conf\workpoint-client.properties in a text editor.
    admin_tools
    is the installed location of the Administrative tools. The Administrative Tools are placed in the following default locations:
    • Windows:
      C:\Program Files\CA\Identity Manager\IAM Suite\Identity Manager\tools
    • UNIX:
      /opt/CA/IdentityManager/IAMocate and 
      comment
      the following settin_Suite/Identity_Manager/tools
  2. Locate the section titled  MTS or EJB configuration and make sure to set the following settings:
    ############################################################################# # MTS or EJB configuration # Determines if the designer will connect to the EJB or MTS server, # or use XML to communicate with a web service (good for firewalls) #client.connect = EJB client.connect = XML # Uncomment 'client.connect.URL' below whenever 'client.connect = XML' is uncommented. # The 'localhost' value may be changed if the Application Server is on a different machine. # The port number here must match the servlet port configured in your Application Server. # By default, the servlet port for JBoss = 8080, WebSphere = 9080, and Weblogic = 7001 client.connect.URL = http://localhost:8080/iam/im/wpClientServlet
    Note:
    You may need to edit the
    client.connect.URL
    property value. For example, replace localhost with server_name or ip and the port with your JBoss server port.
  3. Locate the section titled JBoss SETTINGS under J2EE Client Configuration.
  4. Locate and
    comment
    the following settings:
    java.naming.provider.url=localhost
    java.naming.factory.initial=org.JBoss.as.naming.InitialContextFactory
    java.naming.factory.url.pkgs=org.JBoss.ejb.client.naming
    remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
    remote.connections=default
    remote.connection.default.host=localhost
    remote.connection.default.port=4447
    remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
    client.ejbLookupPrefix=ejb:iam_im/iam_im_wpServer/
    client.ejbLookupSuffix=!<CLASSNAME>
  5. Locate and
    uncomment
    the following settings:
    java.naming.provider.url=http-remoting://localhost:8080
    java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
    client.ejbLookupPrefix=ejb:iam_im/iam_im_wpServer/
    client.ejbLookupSuffix=!<CLASSNAME>
    Note:
    You may need to edit the java.naming.provider.url property value. For example, replace localhost with
    server_name or ip
    and the port with your JBoss server port.
  6. Save the file.
Troubleshooting
Use the following steps to guide you through some issues that you may encounter.
Deployment Fails with WFLYUT0063 Error with Web Service in EAP 7 if There is No http-listener
Symptom:
There is a known issue with EAP 7.x, as described here: https://access.redhat.com/solutions/3464611. Use the following recommended resolution, which involves adding the missing lines to the standalone configuration file:
<subsystem xmlns="urn:jboss:domain:webservices:2.0"> <modify-wsdl-address>true</modify-wsdl-address> <wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host> <wsdl-port>8080</wsdl-port> <wsdl-secure-port>8443</wsdl-secure-port> <wsdl-uri-scheme>https</wsdl-uri-scheme> ... </subsystem>
Solution:
Add the missing lines, which are typically:
<wsdl-port>8080</wsdl-port>
<wsdl-secure-port>8443</wsdl-secure-port>
<wsdl-uri-scheme>https</wsdl-uri-scheme>
The ejb Subsystem with Remote Service Displays an Error during the EAP 7.2 App Server Startup
Symptom:
The ejb subsystem with a remote service displays an error during the EAP 7.2 App Server startup. The message appears similar to the following message:
("subsystem" => "
ejb3
"), ("service" => "
remote
") ]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["jboss.remoting.remotingConnectorInfoService.http-remoting-connector"], "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]", "org.wildfly.ejb.remote is missing [jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"
Solution:
The solution has two parts.
1) For the
remote
subsystem, remove the
remoting-connector
, that is, change the subsystem
From:
<subsystem xmlns="
urn:jboss:domain:remoting:4.0
"> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/> <http-connector name="http-remoting-connector" connector-ref="http" security-realm="ApplicationRealm"/> </subsystem>
To:
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="http" security-realm="ApplicationRealm"/> </subsystem>
2) Change the
connector-ref
that is present in
http-remoting-connector
to use
https
instead of
http
. So change
From:
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="
http
" security-realm="ApplicationRealm"/> </subsystem>
To:
<subsystem xmlns="urn:jboss:domain:remoting:4.0"> <http-connector name="http-remoting-connector" connector-ref="
https
" security-realm="ApplicationRealm"/> </subsystem>
JBoss Modcluster Error
Symptom:
After the migration, the following error appears with a modcluster subsystem:
ERROR [org.JBoss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=modcluster/proxy=default' are not available: org.wildfly.undertow.listener.ajp; Possible registration points for this capability:/subsystem=undertow/server=*/ajp-listener=* /subsystem=undertow/server=*/http-listener=* /subsystem=undertow/server=*/https-listener=* FATAL [org.JBoss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
Solution:
Match the default proxy listener name to the ajp-listener name defined in the undertow subsystem.
For Example:
Release Upgrade Support
And the undertow listener name for the listener: Release Upgrade Support
Migration Script Fails to Start
Symptom:
The migration script fails to start.
Solution:
The value for the JBOSS_HOME environment variable must match the destination folder for the JBoss/WildFly migration. Edit the JBOSS_HOME environment variable accordingly.
Identity Manager Server Startup Failure
Symptom:
The Identity Manager Server fails to start after the migration from WildFly 8.2 to 15.0.1, and displays the following error:
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 86) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.node1_live_to_node2_backup: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.node1_live_to_node2_backup: java.lang.IllegalStateException: java.lang.IllegalArgumentException: java.security.PrivilegedActionException: java.lang.IllegalArgumentException: Unrecognized TCPPING properties: [num_initial_members, timeout]
Solution:
The
num_initial_members
and
timeout
variables are deprecated in EAP 7.2. Comment those two variables in the
standalone-full-ha.xml
file, and then restart the server. 
JBoss EAP Startup Failure
Symptom:
Post-migration, JBoss fails to start with the following error:
ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[ ("core-service" => "management"), ("management-interface" => "native-interface") ]'
Root Cause:
The default deployment timeout for JBoss EAP 7.2 is set to 300 seconds. If the application server takes more than 300 seconds to start, the deployment fails.
Solution:
Increase the deployment timeout to a desired value in the
<JBoss_Home>/bin/standalone.conf
file. For example: Change the timeout value to 600 seconds
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.as.management.blocking.timeout=600"
Errors During the Identity Manager Server Startup Post Migration
Symptom:
Authentication fails during migration with the following errors:
ERROR [ims.llsdk6.ManagedObjectDescriptorTypeProvider] (ServerService Thread Pool -- 103) java.lang.reflect.InvocationTargetException: java.lang.reflect.InvocationTargetExceptionEventually it fails with below error:Caused by: java.lang.SecurityException: PBOX00016: Access denied: authentication failed ERROR [com.netegrity.crypto.AESCBCPKCS5PaddingHandler] (ServerService Thread Pool -- 95) Keyfile '/com/netegrity/config/keys/FIPSkey.dat' not found. Unable to get secret key: /com/netegrity/config/keys/FIPSkey.dat (Too many open files) ERROR [com.netegrity.crypto.AESCBCPKCS5PaddingHandler] (ServerService Thread Pool -- 95) Exception caught while decrypting ERROR [com.netegrity.crypto.AESCBCPKCS5PaddingHandler] (ServerService Thread Pool -- 95) java.lang.NullPointerException
Solution:
There are too many open files.
On all JBoss or WildFly servers, set the Open Files (ulimit –n) to at least 50000 for the user that runs the JBoss or WildFly process, as described here.
Unable to Start JBoss Service
Symptom:
After configuring JBoss 7.2 to run as a Windows service, the JBoss service does not start and the following error is logged in the
stderr
log file:
java.lang.IllegalArgumentException: WFLYSRV0191: Can't use both --server-config and --initial-server-config
Reason:
The
service.bat
file that creates the Windows service does not point to the right
standalone-full.xml
for standalone or
standalone-full-ha.xml
for cluster setup. The file also contains an extra startup parameter (--server-config=!CONFIG!).
Solution:
  1. Open a command line and navigate to the JBoss bin directory.
  2. Uninstall the JBoss service by running the following command:
    service.bat uninstall
  3. Edit the
    service.bat
    file.
    • Change
      "%CONFIG%"=="" set CONFIG=standalone.xml
      to
      Standalone:
      "%CONFIG%"=="" set CONFIG=standalone-full.xml
      Cluster:
      "%CONFIG%"=="" set CONFIG=standalone-full-ha.xml
    • Change
      set STARTPARAM="/c#set#NOPAUSE=Y#&&#!START_SCRIPT!#-Djboss.server.base.dir=!BASE!#--server-config=!CONFIG!"
      to
      set STARTPARAM="/c#set#NOPAUSE=Y#&&#!START_SCRIPT!#-Djboss.server.base.dir=!BASE!#".
  4. Save the file.
  5. Open a command line and navigate to the JBoss bin directory.
  6. Install the JBoss service by running the following command:
    service.bat install