<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

By default, JBoss EAP binds these interfaces to 127.0.0.1 , but these values can be overridden at runtime by setting the appropriate property. For example, the inet-address of the public interface can be set when starting JBoss EAP as a standalone server with the following command.

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

Alternatively, you can use the -b switch on the server start command line. For more information about server start options, see Server Runtime Arguments .

Network interfaces are declared by specifying a logical name and selection criteria for the physical interface. The selection criteria can reference a wildcard address or specify a set of one or more characteristics that an interface or address must have in order to be a valid match. For a listing of all available interface selection criteria, see the Interface Attributes section. Interfaces can be configured using the management console or the management CLI. Below are several examples of adding and updating interfaces. The management CLI command is shown first, followed by the corresponding configuration XML.

Add an Interface with a NIC Value

Add a new interface with a NIC value of eth0 .

/interface=external:add(nic=eth0)

<interface name="external">
   <nic name="eth0"/>
</interface>

Add an Interface with Several Conditional Values

Add a new interface that matches any interface/address on the correct subnet if it is up, supports multicast, and is not point-to-point.

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})

<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <multicast/>
      <point-to-point/>
</interface>

Update an Interface Attribute

Update the public interface’s default inet-address value, keeping the jboss.bind.address property to allow for this value to be set at runtime.

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")

<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>

Add an Interface to a Server in a Managed Domain

/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)

<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>

Management ports were consolidated in JBoss EAP 7. By default, JBoss EAP 7 uses port 9990 for both native management, used by the management CLI, and HTTP management, used by the web-based management console. Port 9999 , which was used as the native management port in JBoss EAP 6, is no longer used but can still be enabled if desired. If HTTPS is enabled for the management console, then port 9993 is used by default.

JBoss EAP ships with a socket binding group for each of the five predefined profiles ( default , ha , full , full-ha , load-balancer ). For detailed information about the default socket bindings, such as default ports and descriptions, see the Default Socket Bindings section.

Standalone Server

When running as a standalone server, only one socket binding group is defined per configuration file. Each standalone configuration file ( standalone.xml , standalone-ha.xml , standalone-full.xml , standalone-full-ha.xml , standalone-load-balancer.xml ) defines socket bindings for the technologies used by its corresponding profile. For example, the default standalone configuration file ( standalone.xml ) specifies the below socket bindings.

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

Managed Domain

When running in a managed domain, all socket binding groups are defined in the domain.xml file. There are five predefined socket binding groups: standard-sockets ha-sockets full-sockets full-ha-sockets load-balancer-sockets Each socket binding group specifies socket bindings for the technologies used by its corresponding profile. For example, the full-ha-sockets socket binding group defines several jgroups socket bindings, which are used by the full-ha profile for high availability.

<socket-binding-groups>
  <socket-binding-group name="standard-sockets" default-interface="public">
    <!-- Needed for server groups using the 'default' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'ha' profile  -->
  </socket-binding-group>
  <socket-binding-group name="full-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full' profile  -->
  </socket-binding-group>
  <socket-binding-group name="full-ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full-ha' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="iiop" interface="unsecure" port="3528"/>
    <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/>
    <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
    <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
    <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
    <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="load-balancer-sockets" default-interface="public">
    <!-- Needed for server groups using the 'load-balancer' profile  -->
  </socket-binding-group>
</socket-binding-groups>

When defining a socket binding, you can configure the port and interface attributes, as well as multicast settings such as multicast-address and multicast-port . For details on all available socket bindings attributes, see the Socket Binding Attributes section. Socket bindings can be configured using the management console or the management CLI. The following steps go through adding a socket binding group, adding a socket binding, and configuring socket binding settings using the management CLI. Add a new socket binding group. Note that this step cannot be performed when running as a standalone server.

/socket-binding-group=new-sockets:add(default-interface=public)

/socket-binding-group=new-sockets/socket-binding=new-socket-binding:add(port=1234)

/socket-binding-group=new-sockets/socket-binding=new-socket-binding:write-attribute(name=interface,value=unsecure)

The following example shows how the XML configuration may look after the above steps have been completed.

<socket-binding-groups>
    <socket-binding-group name="new-sockets" default-interface="public">
        <socket-binding name="new-socket-binding" interface="unsecure" port="1234"/>
    </socket-binding-group>
</socket-binding-groups>

You can view the socket binding name and the open ports for a server from the management console. The information is visible when the server is in the following states: running reload-required restart-required To view the socket bindings and the open ports for a server: Access the management console and navigate to Runtime . Click the server to view the socket binding name and the open ports in the right pane.

A port offset is a numeric offset value added to all port values specified in the socket binding group for that server. This allows the server to inherit the port values defined in its socket binding group, with an offset to ensure that it does not conflict with any other servers on the same host. For instance, if the HTTP port of the socket binding group is 8080 , and a server uses a port offset of 100 , then its HTTP port is 8180 . Below is an example of setting a port offset of 250 for a server in a managed domain using the management CLI.

/host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

Port offsets can be used for servers in a managed domain and for running multiple standalone servers on the same host. You can pass in a port offset when starting a standalone server using the jboss.socket.binding.port-offset property.

$ EAP_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100

Deploy an Application

From the management CLI, use the deployment deploy-file command and specify the path to the application deployment.

deployment deploy-file /path/to/test-application.war

A successful deployment does not produce any output to the management CLI, but the server log displays deployment messages.

WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
WFLYUT0021: Registered web context: /test-application
WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

Similarly, you can use the following deployment commands: Use the deployment deploy-cli-archive to deploy the content from a .cli archive file. A CLI deployment archive is a JAR file with the .cli extension. It contains application archives that should be deployed and the CLI script files, deploy.scr and undeploy.scr , containing commands and operations. One script file, deploy.scr , contains the commands and operations that deploy the application archives and set up the environment; the other script file, undeploy.scr , contains the commands to undeploy the application archives and clean up the environment. Use the deployment deploy-url to deploy the content referenced by a URL. You can also enable the disabled applications using the deployment enable command .

Undeploy an Application

From the management CLI, use the deployment undeploy command and specify the deployment name. This will delete the deployment content from the repository. See Disable an Application for keeping the deployment content when undeploying.

deployment undeploy test-application.war

A successful undeployment does not produce any output to the management CLI, but the server log displays undeployment messages.

WFLYUT0022: Unregistered web context: /test-application
WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 62ms
WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

Similarly, you can use the deployment undeploy-cli-archive to undeploy the content from a .cli archive file. You can also undeploy all deployments using a wildcard ( * ).

deployment undeploy *

Disable an Application

Disable a deployed application without removing the deployment content from the repository.

deployment disable test-application.war

You can use the deployment disable-all command to disable all the deployments.

deployment disable-all

Enable an Application

Enable a disabled deployed application.

deployment enable test-application.war

You can use the deployment enable-all command to enable all the deployments.

deployment enable-all

List Deployments

From the management CLI, use the deployment info command to list deployment information.

deployment info

The output will show details about each deployment, such as the runtime name, status, and whether it is enabled.

NAME                 RUNTIME-NAME         PERSISTENT ENABLED STATUS
helloworld.war       helloworld.war       true       true    OK
test-application.war test-application.war true       true    OK

To display deployment information by name:

deployment info helloworld.war

You can also list all the deployments using the deployment list command.

Deploy an Application

From the management CLI, use the deployment deploy-file command and specify the path to the application deployment. You must also specify the server groups to which the application should be deployed. To deploy the application to all server groups.

deployment deploy-file /path/to/test-application.war --all-server-groups

deployment deploy-file /path/to/test-application.war --server-groups=main-server-group,other-server-group

A successful deployment does not produce any output to the management CLI, but the server log displays deployment messages for each affected server.

[Server:server-one] WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
[Server:server-one] WFLYUT0021: Registered web context: /test-application
[Server:server-one] WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

Similarly, you can use the following deployment commands: Use the deployment deploy-cli-archive command to deploy the content from a .cli archive file. A CLI deployment archive is a JAR file with the .cli extension. It contains application archives that should be deployed and the CLI script files, deploy.scr and undeploy.scr , containing commands and operations. One script file, deploy.scr , contains the commands and operations that deploy the application archives and set up the environment; the other script file, undeploy.scr , contains the commands to undeploy the application archives and clean up the environment. Use the deployment deploy-url command to deploy the content referenced by a URL. You can also enable the disabled applications using the deployment enable command .

Undeploy an Application

From the management CLI, use the deployment undeploy command and specify the deployment name. You must also specify the server groups from which the application should be undeployed. See Disable an Application for undeploying from specific server groups. Undeploy the application from all server groups with that deployment.

deployment undeploy test-application.war --all-relevant-server-groups

A successful undeployment does not produce any output to the management CLI, but the server log displays undeployment messages for each affected server.

[Server:server-one] WFLYUT0022: Unregistered web context: /test-application
[Server:server-one] WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 74ms
[Server:server-one] WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

Similarly, you can use the deployment undeploy-cli-archive command to undeploy the content from a .cli archive file. You can also undeploy all deployments using a wildcard ( * ).

deployment undeploy * --all-relevant-server-groups

Disable an Application

Disable a deployed application from specific server groups and retain its content in the repository for other server groups with that deployment.

deployment disable test-application.war --server-groups=other-server-group

You can use the deployment disable-all command to disable all the deployments.

deployment disable-all --server-groups=other-server-group

Enable an Application

Enable a disabled deployed application.

deployment enable test-application.war

You can use the deployment enable-all command to enable all the deployments.

deployment enable-all --server-groups=other-server-group

List Deployments

From the management CLI, use the deployment info command to list deployment information. You can list deployment information by deployment name or by server group. To display deployment information by name:

deployment info helloworld.war

The output will list the deployment and its state in each server group.

NAME               RUNTIME-NAME
helloworld.war     helloworld.war
SERVER-GROUP       STATE
main-server-group  enabled
other-server-group added

To display deployment information by server group:

deployment info --server-group=other-server-group

The output will list the deployments and their state for the specified server group.

NAME                 RUNTIME-NAME         STATE
helloworld.war       helloworld.war       added
test-application.war test-application.war enabled

You can also list all deployments in the domain using the deployment list command.

Deployments can be viewed and managed from the Deployments tab of the JBoss EAP management console.

Deploy an Application

Click the Add ( + ) button. You can choose to deploy an application by uploading a deployment , adding an unmanaged deployment , or creating an empty deployment . Deployments are enabled by default. Upload a deployment Upload an application that will be copied to the server’s content repository and managed by JBoss EAP. Adding an unmanaged deployment Specify the location of a deployment. This deployment will not be copied to the server’s content repository and will not be managed by JBoss EAP. Creating an empty deployment Create an empty, exploded deployment. You can add files to the deployment after it has been created.

Undeploy an Application

Select the deployment and choose the Undeploy option. JBoss EAP removes the deployment from the content repository.

Disable an Application

Select the deployment and choose the Disable option to disable the application. This undeploys the deployment, but does not remove it from the content repository.

Replace an Application

Select the deployment and choose the Replace option. Select the new version of the deployment, which must have the same name as the original, and click Finish . This undeploys and removes the original version of the deployment, and then deploys the new version.

From the Deployments tab of the JBoss EAP management console, deployments can be viewed and managed by: Content Repository All managed and unmanaged deployments are listed in the Content Repository section. Deployments can be added and deployed to server groups here. Server Groups Deployments that have been deployed to one or more server groups are listed in the Server Groups section. Deployments can be enabled and added directly to a server group here.

Add an Application

Deploy an Application to a Server Group

Undeploy an Application from a Server Group

The deployment scanner can be configured to allow or disallow automatic deployment of XML, zipped, and exploded content. If automatic deployment is disabled, you must manually create marker files to trigger deployment actions. For more information about the available marker file types and their purposes, see the Deployment Scanner Marker Files section. By default, automatic deployment for XML and zipped content is enabled. For details on configuring automatic deployment for each content type, see Configure the Deployment Scanner .

Deploy an Application

Copy the content to the deployment folder.

$ cp /path/to/test-application.war EAP_HOME/standalone/deployments/

If auto-deployment is enabled, this file will be picked up automatically, deployed, and a .deployed marker file will be created. If auto-deployment is not enabled, then you will need to manually add a .dodeploy marker file to trigger deployment.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

Undeploy an Application

Trigger an undeployment by removing the .deployed marker file.

$ rm EAP_HOME/standalone/deployments/test-application.war.deployed

If auto-deployment is enabled, you can also remove the test-application.war file, which will trigger the undeployment. Note that this does not apply for exploded deployments.

Redeploy an Application

Create a .dodeploy marker file to initiate redeployment.

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

The deployment scanner can be configured using the management console or the management CLI. You can configure the deployment scanner’s behavior, such as the scan interval, deployment folder location, and autodeployment of certain application file types. You can also disable the deployment scanner entirely. For details on all available deployment scanner attributes, see the Deployment Scanner Attributes section. Use the below management CLI commands to configure the default deployment scanner.

Disable the Deployment Scanner

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)

This disables the default deployment scanner.

Change the Scan Interval

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=10000)

This updates the scan interval time from 5000 milliseconds (five seconds) to 10000 milliseconds (ten seconds).

Change the Deployment Folder

/subsystem=deployment-scanner/scanner=default:write-attribute(name=path,value=/path/to/deployments)

This changes the location of the deployment folder from the default location of EAP_HOME /standalone/deployments to /path/to /deployments . The path value will be treated as an absolute path unless the relative-to attribute is specified, in which case it will be relative to that path.

Enable the Automatic Deployment of Exploded Content

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)

This enables the automatic deployment of exploded content, which is disabled by default.

Disable the Automatic Deployment of Zipped Content

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-zipped,value=false)

This disables the automatic deployment of zipped content, which is enabled by default.

Disable the Automatic Deployment of XML Content

/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-xml,value=false)

This disables the automatic deployment of XML content, which is enabled by default.

A new deployment scanner can be added using the management CLI or by navigating to the Deployment Scanners subsystem from the Configuration tab in the management console. This will define a new directory to scan for deployments. The default deployment scanner monitors EAP_HOME /standalone/deployments . See Configure the Deployment Scanner for details on configuring an existing deployment scanner. The following management CLI command adds a new deployment scanner that will check EAP_HOME /standalone/new_deployment_dir every five seconds for deployments.

/subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)

The following instructions show how to deploy and undeploy the JBoss EAP helloworld quickstart to a standalone server using Maven. See Using the Quickstart Examples in the JBoss EAP Getting Started Guide for more information on the JBoss EAP quickstarts.

Deploy an Application

Initialize the WildFly Maven Plugin in your Maven pom.xml file. This should already be configured in the JBoss EAP quickstart pom.xml files.

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
</plugin>

From the helloworld quickstart directory, execute the following Maven command.

$ mvn clean install wildfly:deploy

After issuing the Maven command to deploy, the terminal window shows the following output indicating a successful deployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.981 s
[INFO] Finished at: 2015-12-23T15:06:13-05:00
[INFO] Final Memory: 21M/231M
[INFO] ------------------------------------------------------------------------

The deployment can also be confirmed by viewing the server log of the active server instance.

WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war")
WFLYUT0021: Registered web context: /helloworld
WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")

Undeploy an Application

From the helloworld quickstart directory, execute the following Maven command.

$ mvn wildfly:undeploy

After issuing the Maven command to undeploy, the terminal window shows the following output indicating a successful undeployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.237 s
[INFO] Finished at: 2015-12-23T15:09:10-05:00
[INFO] Final Memory: 10M/183M
[INFO] ------------------------------------------------------------------------

The undeployment can also be confirmed by viewing the server log of the active server instance.

WFLYUT0022: Unregistered web context: /helloworld
WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 27ms
WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")

The following instructions show how to deploy and undeploy the JBoss EAP helloworld quickstart in a managed domain using Maven. See Using the Quickstart Examples in the JBoss EAP Getting Started Guide for more information on the JBoss EAP quickstarts.

Deploy an Application

When deploying an application in a managed domain, you must specify the server groups to which the application should be deployed. This is configured in the Maven pom.xml file. The following configuration in the pom.xml initializes the WildFly Maven Plugin and specifies main-server-group as the server group to which the application should be deployed.

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
  <configuration>
    <domain>
      <server-groups>
        <server-group>main-server-group</server-group>
      </server-groups>
    </domain>
  </configuration>
</plugin>

From the helloworld quickstart directory, execute the following Maven command.

$ mvn clean install wildfly:deploy

After issuing the Maven command to deploy, the terminal window shows the following output indicating a successful deployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.005 s
[INFO] Finished at: 2016-09-02T14:36:17-04:00
[INFO] Final Memory: 21M/226M
[INFO] ------------------------------------------------------------------------

The deployment can also be confirmed by viewing the server log of the active server instance.

WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war")
WFLYUT0021: Registered web context: /helloworld
WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")

Undeploy an Application

From the helloworld quickstart directory, execute the following Maven command.

$ mvn wildfly:undeploy

After issuing the Maven command to undeploy, the terminal window shows the following output indicating a successful undeployment.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.750 s
[INFO] Finished at: 2016-09-02T14:45:10-04:00
[INFO] Final Memory: 10M/184M
[INFO] ------------------------------------------------------------------------

The undeployment can also be confirmed by viewing the server log of the active server instance.

WFLYUT0022: Unregistered web context: /helloworld
WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 106ms
WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")

By default, the HTTP API is accessible at http:// HOST : PORT /management , for example, http://localhost:9990/management .

Deploy an Application

$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}]},{"operation" : "deploy", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

Undeploy an Application

$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "test-application.war"}},{"operation" : "remove", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

See this Red Hat Knowledgebase article to learn more about programmatically generating the JSON requests.

By default, the HTTP API is accessible at http:// HOST : PORT /management , for example, http://localhost:9990/management .

Deploy an Application

Undeploy an Application

You can define a custom location for JBoss EAP to store deployed content.

Define a Custom Directory for a Standalone Server

By default, deployed content for a standalone server is stored in the EAP_HOME /standalone/data/content directory. This location can be changed by passing in the -Djboss.server.deploy.dir argument when starting the server.

$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content

The chosen location should be unique among JBoss EAP instances. The jboss.server.deploy.dir property specifies the directory to be used for storing content that has been deployed using the management console or management CLI. To define a custom deployment directory to be monitored by the deployment scanner, see Configure the Deployment Scanner .

Define a Custom Directory for a Managed Domain

By default, deployed content for a managed domain is stored in the EAP_HOME /domain/data/content directory. This location can be changed by passing in the -Djboss.domain.deployment.dir argument when starting the domain.

$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content

The chosen location should be unique among JBoss EAP instances.

JBoss EAP offers fine-grained control over the order of deployments when the server is started. Strict order of the deployment of applications present in multiple EAR files can be specified along with persistence of the order after a restart. You can use the jboss-all.xml deployment descriptor to declare dependencies between top-level deployments. For example, if you have an app.ear that depends on framework.ear being deployed first, then you can create an app.ear/META-INF/jboss-all.xml file as shown below.

<jboss xmlns="urn:jboss:1.0">
  <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
    <dependency name="framework.ear" />
  </jboss-deployment-dependencies>
</jboss>

A deployment overlay can be used to overlay content into an existing deployment without physically modifying the contents of the deployment archive. It allows you to override deployment descriptors, library JAR files, classes, JSP pages, and other files at runtime without rebuilding the archive. This can be useful if you need to adapt a deployment for different environments that need different configurations or settings. For example, when moving a deployment through the application lifecycle from development, to testing, to stage, and finally into production, you might want to swap deployment descriptors, modify static web resources to change the branding of the application, or even replace JAR libraries with different versions depending on the target environment. It is also a useful feature for installations that need to change a configuration but can not modify or crack an archive due to policy or security restrictions. When defining a deployment overlay, you specify the file on a file system that will replace the file in the deployment archive. You must also specify which deployments should be affected by the deployment overlay. Any affected deployments must be redeployed in order for the changes to take effect.

About Rollout Plans

In a managed domain, operations targeted at domain or host level resources can potentially impact multiple servers. Such operations can include a roll out plan detailing the sequence in which the operation would be applied to the servers, as well as the policies for detailing whether the operation could be reverted if it fails to execute successfully on some servers. If no rollout plan is specified, the default rollout plan is used. Below is an example rollout plan involving five server groups. Operations can be applied to server groups serially, in-series , or concurrently, concurrent-groups . The syntax is described in more detail in Rollout Plan Syntax .

{"my-rollout-plan" => {"rollout-plan" => {
    "in-series" => [
        {"concurrent-groups" => {
            "group-A" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            "group-B" => undefined
        {"server-group" => {"group-C" => {
            "rolling-to-servers" => "false",
            "max-failed-servers" => "1"
        {"concurrent-groups" => {
            "group-D" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            "group-E" => undefined
    "rollback-across-groups" => "true"
					Looking at the example above, applying the operation to the servers in the domain is done in three phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well.
							Server groups group-A




    
 and group-B will have the operation applied concurrently. The operation will be applied to the servers in group-A in series, while all servers in group-B will handle the operation concurrently. If more than 20% of the servers in group-A fail to apply the operation, it will be rolled back across that group. If any servers in group-B fail to apply the operation it will be rolled back across that group.
							Once all servers in group-A and group-B are complete, the operation will be applied to the servers in group-C. Those servers will handle the operation concurrently. If more than one server in group-C fails to apply the operation it will be rolled back across that group.
							Once all servers in group-C are complete, server groups group-D and group-E will have the operation applied concurrently. The operation will be applied to the servers in group-D in series, while all servers in group-E will handle the operation concurrently. If more than 20% of the servers in group-D fail to apply the operation, it will be rolled back across that group. If any servers in group-E fail to apply the operation it will be rolled back across that group.
						
Rollout Plan Syntax

					You can specify a rollout plan in either of the following ways.
							By defining the rollout plan in the deploy command operation headers. See Deploy Using a Rollout Plan for details.
							By storing the rollout plan using the rollout-plan command and then referencing the plan name in the deploy command operation headers. See Deploy Using a Stored Rollout Plan for details.
					Although each method has a different initial command, both methods use the rollout operation header to define the rollout plan. This uses the following syntax.
				
rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]

							PLAN_NAME is the name for the rollout plan that was stored using the rollout-plan command.
							SERVER_GROUP_LIST is the list of server groups. Use a comma (,) to separate multiple server groups to indicate that operations should be performed on each server group sequentially. Use a caret (^) separator to indicate that operations should be performed on each server group concurrently.
									For each server group, set any of the following policies in parentheses. Use a comma to separate multiple policies.
											rolling-to-servers: A boolean that, if set to true, applies the operation to each server in the group in series. If the value is false or not specified, the operation will be applied to the servers in the group concurrently.
											max-failed-servers: An integer which takes the maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is 0, meaning that a failure on any server will trigger rollback across the group.
											max-failure-percentage: An integer between 0 and 100 that represents the maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is 0, meaning that a failure on any server will trigger rollback across the group.
												If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
							rollback-across-groups: A boolean that indicates whether the need to rollback the operation on all the servers in one server group triggers a rollback across all the server groups. This defaults to false.
						
Deploy Using a Rollout Plan

					You can provide the full details of a rollout plan directly to the deploy command by passing the rollout settings into the headers argument. See the Rollout Plan Syntax for more information on the format.
					The following management CLI command deploys an application to the main-server-group server group using a deployment plan that specifies rolling-to-servers=true for serial deployment.
				
deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
Deploy Using a Stored Rollout Plan

					Since rollout plans can be complex, you have the option to store the details of a rollout plan. This allows you to reference the rollout plan name when you want to use it instead of requiring the full details of the rollout plan each time.
							Use the rollout-plan management CLI command to store a rollout plan. See the Rollout Plan Syntax for more information on the format.
						
rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}

							This creates the following deployment plan.
						
"rollout-plan" => {
    "in-series" => [
        {"server-group" => {"main-server-group" => {
            "rolling-to-servers" => false,
            "max-failed-servers" => 1
        {"server-group" => {"other-server-group" => {
            "rolling-to-servers" => true,
            "max-failure-percentage" => 20
    "rollback-across-groups" => true
							Specify the stored rollout plan name when deploying the application.
							The following management CLI command deploys an application to all server groups using the my-rollout-plan stored rollout plan.
						
deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
Remove a Stored Rollout Plan

					You can remove a stored rollout plan using the rollout-plan management CLI command by specifying the name of the rollout plan to remove.
				
rollout-plan remove --name=my-rollout-plan
Default Rollout Plan

					All operations that impact multiple servers will be executed with a rollout plan. If no rollout plan is specified in the operation request, a default rollout plan will be generated. The plan will have the following characteristics.
							There will only be a single high-level phase. All server groups affected by the operation will have the operation applied concurrently.
							Within each server group, the operation will be applied to all servers concurrently.
							Failure on any server in a server group will cause rollback across the group.
							Failure of any server group will result in rollback of all other server groups.
						

Use the browse-content operation to view the files and directories in a managed deployment. Provide no arguments to return the entire deployment structure or use the path argument to provide the path to a specific directory. You can also browse contents of a deployment from the management console by navigating to the Deployments tab, selecting the deployment, and selecting View from the drop down.

/deployment=helloworld.war:browse-content(path=META-INF/)

This displays the files and directories in the META-INF/ directory of the helloworld.war deployment. "outcome" => "success", "result" => [ "path" => "MANIFEST.MF", "directory" => false, "file-size" => 827L "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.properties", "directory" => false, "file-size" => 106L "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.xml", "directory" => false, "file-size" => 2713L "path" => "maven/org.jboss.eap.quickstarts/helloworld/", "directory" => true "path" => "maven/org.jboss.eap.quickstarts/", "directory" => true "path" => "maven/", "directory" => true "path" => "INDEX.LIST", "directory" => false, "file-size" => 251L You can also specify the following arguments to the browse-content operation.

You can read the contents of a file in a managed deployment using the read-content operation. Provide no arguments to return the entire deployment or use the path argument to provide the path to a specific file. For example:

/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

This returns a file stream, which can be displayed in the management CLI or saved to the file system . "outcome" => "success", "result" => {"uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95"}, "response-headers" => {"attached-streams" => [{ "uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95", "mime-type" => "text/plain" }

attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

ATTACHMENT 8af87836-2abd-423a-8e44-e731cc57bd80:
Manifest-Version: 1.0
Implementation-Title: Quickstart: helloworld
Implementation-Version: 7.3.0.GA
Java-Version: 1.8.0_131
Built-By: username
Scm-Connection: scm:git:[email protected]:jboss/jboss-parent-pom.git/quic
 kstart-parent/helloworld
Specification-Vendor: JBoss by Red Hat
...

attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF

A domain controller is the JBoss EAP server instance that acts as a central management point for a domain. One host controller instance is configured to act as a domain controller. The primary responsibilities of the domain controller are: Maintain the domain’s central management policy. Ensure all host controllers are aware of its current contents. Assist the host controllers in ensuring that all running JBoss EAP server instances are configured in accordance with this policy. By default, the central management policy is stored in the EAP_HOME /domain/configuration/domain.xml file. This file is required in this directory of the host controller that is set to run as the domain controller. The domain.xml file contains profile configurations available for use by the servers in the domain. A profile contains the detailed settings of the various subsystems available in that profile. The domain configuration also includes the definition of socket groups and the server group definitions. It is possible for a JBoss EAP 7 domain controller to administer JBoss EAP 6 hosts and servers, as long as the hosts and servers are running JBoss EAP 6.2 or later. For more information, see Configure a JBoss EAP 7.x Domain Controller to Administer JBoss EAP 6 Instances . For more information, see the Start a Managed Domain and Domain Controller Configuration sections.

The primary responsibility of a host controller is server management. It delegates domain management tasks and is responsible for starting and stopping the individual application server processes that run on its host. It interacts with the domain controller to help manage the communication between the servers and the domain controller. Multiple host controllers of a domain can interact with only a single domain controller. Hence, all the host controllers and server instances running on a single domain mode have a single domain controller and must belong to the same domain. By default, each host controller reads its configuration from the EAP_HOME /domain/configuration/host.xml file located in the unzipped JBoss EAP installation file on its host’s file system. The host.xml file contains the following configuration information that is specific to the particular host: The names of the server instances meant to run from this installation. Configurations specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml . And abstract path names in domain.xml can be mapped to actual file system paths in host.xml . Any of the following configurations: How the host controller contacts the domain controller to register itself and access the domain configuration. How to find and contact a remote domain controller. Whether the host controller is to act as the domain controller For more information, see the Start a Managed Domain and Host Controller Configuration sections.

A process controller is a small, lightweight process that is responsible for spawning the host controller process and monitoring its lifecycle. If the host controller crashes, the process controller will restart it. It also starts server processes as directed by the host controller; however, it will not automatically restart server processes that crash. The process controller logs to the EAP_HOME /domain/log/process-controller.log file. You can set JVM options for the process controller in the EAP_HOME /bin/domain.conf file using the PROCESS_CONTROLLER_JAVA_OPTS variable.

A server group is a collection of server instances that are managed and configured as one. In a managed domain, every application server instance belongs to a server group, even if it is the only member. The server instances in a group share the same profile configuration and deployed content. A domain controller and a host controller enforce the standard configuration on all server instances of every server group in its domain. A domain can consist of multiple server groups. Different server groups can be configured with different profiles and deployments. For example, a domain can be configured with different server tiers providing different services. Different server groups can also have the same profile and deployments. This can, for example, allow for rolling application upgrades where the application is upgraded on one server group and then updated on a second server group, avoiding a complete service outage. For more information, see the Configuring Server Groups section.

A server represents an application server instance. In a managed domain, all server instances are members of a server group. The host controller launches each server instance in its own JVM process. For more information, see the Configuring Servers section.

Domain and host controllers can be started using the domain.sh or domain.bat script provided with JBoss EAP. For a complete listing of all available startup script arguments and their purposes, use the --help argument or see the Server Runtime Arguments section. The domain controller must be started before any slave servers in any server groups in the domain. Start the domain controller first, then start any other associated host controllers in the domain.

Start the Domain Controller

Start the domain controller with the host-master.xml configuration file, which is preconfigured for a dedicated domain controller.

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml

Depending on your domain setup, you will need to make additional configurations to allow host controllers to connect. Also see the following example domain setups: Set Up a Managed Domain on a Single Machine Set Up a Managed Domain on Two Machines

Start a Host Controller

Start the host controller with the host-slave.xml configuration file, which is preconfigured for a slave host controller.

$ EAP_HOME/bin/domain.sh  --host-config=host-slave.xml

Depending on your domain setup, you will need to make additional configurations connect to, and not conflict with, the domain controller. Also see the following example domain setups: Set Up a Managed Domain on a Single Machine Set Up a Managed Domain on Two Machines

You must configure one host in the domain as the domain controller.

<domain-controller>
  <local/>
</domain-controller>

<management-interfaces>
  <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
    <socket interface="management" port="${jboss.management.http.port:9990}"/>
  </http-interface>
</management-interfaces>

A host controller must be configured to connect to the domain controller so that the host controller can register itself with the domain.

<domain-controller>
  <remote security-realm="ManagementRealm">
    <discovery-options>
      <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
    </discovery-options>
  </remote>
</domain-controller>

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=IP_ADDRESS

Every host running in a managed domain must have a unique host name. To ease administration and allow for the use of the same host configuration files on multiple hosts, the server uses the following precedence for determining the host name. If set, the host element name attribute in the host.xml configuration file. The value of the jboss.host.name system property. The value that follows the final period ( . ) character in the jboss.qualified.host.name system property, or the entire value if there is no final period ( . ) character. The value that follows the period ( . ) character in the HOSTNAME environment variable for POSIX-based operating systems, the COMPUTERNAME environment variable for Microsoft Windows, or the entire value if there is no final period ( . ) character. A host controller’s name is configured in the host element at the top of the relevant host.xml configuration file, for example:

<host xmlns="urn:jboss:domain:8.0" name="host1">

Use the following procedure to update the host name using the management CLI. Start the JBoss EAP host controller.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml

$ EAP_HOME/bin/jboss-cli.sh --connect --controller=DOMAIN_CONTROLLER_IP_ADDRESS

/host=EXISTING_HOST_NAME:write-attribute(name=name,value=NEW_HOST_NAME)

<host name="NEW_HOST_NAME" xmlns="urn:jboss:domain:8.0">

reload --host=EXISTING_HOST_NAME

If a host controller does not have a name set in the configuration file, you can also pass in the host name at runtime.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.host.name=HOST_NAME

The following is an example of a server group definition:

<server-group name="main-server-group" profile="full">
  <jvm name="default">
    <heap size="64m" max-size="512m"/>
  <socket-binding-group ref="full-sockets"/>
  <deployments>
    <deployment name="test-application.war" runtime-name="test-application.war"/>
    <deployment name="helloworld.war" runtime-name="helloworld.war" enabled="false"/>
  </deployments>
</server-group>

Server groups can be configured using the management CLI or from the management console Runtime tab.

Add a Server Group

The following management CLI command can be used to add a server group.

/server-group=SERVER_GROUP_NAME:add(profile=PROFILE_NAME,socket-binding-group=SOCKET_BINDING_GROUP_NAME)

Update a Server Group

The following management CLI command can be used to update server group attributes.

/server-group=SERVER_GROUP_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)

Remove a Server Group

The following management CLI command can be used to remove a server group.

/server-group=SERVER_GROUP_NAME:remove

Server Group Attributes

A server group requires the following attributes: name : The server group name. profile : The server group profile name. socket-binding-group : The default socket binding group used for servers in the group. This can be overridden on a per-server basis. A server group includes the following optional attributes: management-subsystem-endpoint : Set to true to have servers belonging to the server group connect back to the host controller using the endpoint from their remoting subsystem. The remoting subsystem must be present for this to work. socket-binding-default-interface : The socket binding group default interface for this server. socket-binding-port-offset : The default offset to be added to the port values given by the socket binding group. deployments : The deployment content to be deployed on the servers in the group. jvm : The default JVM settings for all servers in the group. The host controller merges these settings with any other configuration provided in host.xml to derive the settings used to launch the server’s JVM. deployment-overlays : Links between a defined deployment overlay and deployments in this server group. system-properties : The system properties to be set on servers in the group.

The default host.xml configuration file defines three servers:

<servers>
  <server name="server-one" group="main-server-group">
  </server>
  <server name="server-two" group="main-server-group" auto-start="true">
    <socket-bindings port-offset="150"/>
  </server>
  <server name="server-three" group="other-server-group" auto-start="false">
    <socket-bindings port-offset="250"/>
  </server>
</servers>

A server instance named server-one is associated with main-server-group and inherits the subsystem configuration and socket bindings specified by that server group. A server instance named server-two is also associated with main-server-group , but also defines a socket binding port-offset value, so as not to conflict with the port values used by server-one . A server instance named server-three is associated with other-server-group and uses that group’s configurations. It also defines a port-offset value and sets auto-start to false so that this server does not start when the host controller starts. Servers can be configured using the management CLI or from the management console Runtime tab.

Add a Server

The following management CLI command can be used to add a server.

/host=HOST_NAME/server-config=SERVER_NAME:add(group=SERVER_GROUP_NAME)

Update a Server

The following management CLI command can be used to update server attributes.

/host=HOST_NAME/server-config=SERVER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)

Remove a Server

The following management CLI command can be used to remove a server.

/host=HOST_NAME/server-config=SERVER_NAME:remove

Server Attributes

A server requires the following attributes: name : The name of the server. group : The name of a server group from the domain model. A server includes the following optional attributes: auto-start : Whether or not this server should be started when the host controller starts. socket-binding-group : The socket binding group to which this server belongs. socket-binding-port-offset : An offset to be added to the port values given by the socket binding group for this server. update-auto-start-with-server-status : Update the auto-start attribute with the status of the server. interface : A list of fully-specified named network interfaces available for use on the server. jvm : The JVM settings for this server. If not declared, the settings are inherited from the parent server group or host. path : A list of named file system paths. system-property : A list of system properties to set on this server.

You can perform operations on servers, such as starting, stopping, and reloading, from the management console by navigating to the Runtime tab and selecting the appropriate host or server group. See the below commands for performing these operations using the management CLI.

Start Servers

You can start a single server on a particular host.

/host=HOST_NAME/server-config=SERVER_NAME:start

You can start all servers in a specified server group.

/server-group=SERVER_GROUP_NAME:start-servers

Stop Servers

You can stop a single server on a particular host.

/host=HOST_NAME/server-config=SERVER_NAME:stop

You can stop all servers in a specified server group.

/server-group=SERVER_GROUP_NAME:stop-servers

Reload Servers

You can reload a single server on a particular host.

/host=HOST_NAME/server-config=SERVER_NAME:reload

You can reload all servers in a specified server group.

/server-group=SERVER_GROUP_NAME:reload-servers

Kill Servers

You can kill all server processes in a specified server group.

/server-group=SERVER_GROUP_NAME:kill-servers

The following is an example of how to configure a host controller with multiple options for finding the domain controller.

<domain-controller>
  <remote security-realm="ManagementRealm">
    <discovery-options>
      <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.100" port="${jboss.domain.master.port:9990}"/>
      <static-discovery name="backup" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.101" port="${jboss.domain.master.port:9990}"/>
    </discovery-options>
  </remote>
</domain-controller>

A host controller can be started without a connection to the domain controller by using the --cached-dc option; however, the host controller must have previously cached its domain configuration locally from the domain controller. Starting a host controller with this --cached-dc option will cache the host controller’s domain configuration from the domain controller.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --cached-dc

This creates a domain.cached-remote.xml file in the EAP_HOME /domain/configuration/ directory that contains the information necessary for this host controller to temporarily manage its current servers without a domain controller connection. By default, using the --cached-dc option only caches configuration used by this host controller, which means that it cannot be promoted to domain controller for the entire domain. See Cache the Domain Configuration for information on caching the entire domain configuration to allow a host controller to act as the domain controller. If the domain controller is unavailable when starting this host controller with --cached-dc , the host controller will start using the cached configuration saved in the domain.cached-remote.xml file. Note that this file must exist or the host controller will fail to start. While in this state, the host controller cannot modify the domain configuration, but can launch servers and manage deployments. Once started with the cached configuration, the host controller will continue to attempt to reconnect to the domain controller. Once the domain controller becomes available, the host controller will automatically reconnect to it and synchronize the domain configuration. Note that some configuration changes may require you to reload the host controller to take effect. A warning will be logged on the host controller if this occurs.

You can promote a host controller to act as the domain controller if a problem arises with the primary domain controller. The host controller must first cache the domain configuration locally from the domain controller before it can be promoted .

Cache the Domain Configuration

Use the --backup option for any host controller that you might want to become the domain controller.

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --backup

This creates a domain.cached-remote.xml file in the EAP_HOME /domain/configuration/ directory that contains a copy of the entire domain configuration. This configuration will be used if the host controller is reconfigured to act as the domain controller. The ignore-unused-configuration attribute is used to determine how much configuration to cache for a particular host. A value of true means that only the configuration relevant to this host controller is cached, which would not allow it to take over as domain controller. A value of false means that the entire domain configuration is cached. The --backup argument defaults this attribute to false to cache the entire domain. However, if you set this attribute in the host.xml file, that value is used. You can also use the --cached-dc option alone to create a copy of the domain configuration, but must set ignore-unused-configuration to false in the host.xml to cache the entire domain. For example:

<domain-controller>
  <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false">
    <discovery-options>
    </discovery-options>
  </remote>
</domain-controller>

Promote a Host Controller to Be the Domain Controller

This host controller will now act as the domain controller.

You can run multiple host controllers on a single machine by using the jboss.domain.base.dir property.

$ cp -r EAP_HOME/domain /path/to/domain1

$ cp -r EAP_HOME/domain /path/to/host1

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.domain.base.dir=/path/to/domain1

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.base.dir=/path/to/host1 -Djboss.domain.master.address=IP_ADDRESS -Djboss.management.http.port=PORT

<host xmlns="urn:jboss:domain:8.0" name="HOST_NAME">
  <management>
    <security-realms>
      <security-realm name="ManagementRealm">
        <server-identities>
          <secret value="SECRET_VALUE" />
        </server-identities>
									Start the host controller.
									Specify the host-slave.xml configuration file, which is preconfigured for a slave host controller. Also, set the jboss.domain.master.address property to connect to the domain controller and the jboss.bind.address property to set the host controller bind address.
								
$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=IP1  -Djboss.bind.address=IP2

You can now manage the domain from the management CLI by specifying the domain controller address with the --controller parameter when launching.

$ EAP_HOME/bin/jboss-cli.sh --connect --controller=IP1

Or you can manage the domain from the management console at http:// IP1 :9990 .

A JBoss EAP 7.1 domain controller can manage hosts and servers running JBoss EAP 6 as long as they are JBoss EAP 6.2 or later. For a JBoss EAP 7.0 domain controller managing JBoss EAP 7.0 hosts that are on a different patch release, there are no configuration changes needed. However, the JBoss EAP 7.0 domain controller must be running a patch release that is equal to or higher than the versions on the host controllers that it manages. Complete the following tasks to successfully manage JBoss EAP 6 instances in a JBoss EAP 7 managed domain. Add the JBoss EAP 6 configuration to the JBoss EAP 7 domain controller . Update the behavior for the JBoss EAP 6 profiles . Set the server group for the JBoss EAP 6 servers . Prevent the JBoss EAP 6 instances from receiving JBoss EAP 7 updates . Once these tasks are complete, you can manage your JBoss EAP 6 servers and configurations from the JBoss EAP 7 domain controller using the management CLI. Note that JBoss EAP 6 hosts will not be able to take advantage of new JBoss EAP 7 features, such as batch processing.

<profiles>
  <profile name="eap6-default">
  </profile>
</profiles>

<extensions>
  <extension module="org.jboss.as.configadmin"/>
  <extension module="org.jboss.as.threads"/>
  <extension module="org.jboss.as.web"/>
<extensions>

<socket-binding-groups>
  <socket-binding-group name="eap6-standard-sockets" default-interface="public">
  </socket-binding-group>
</socket-binding-groups>

<server-groups>
  <server-group name="eap6-main-server-group" profile="eap6-default">
    <socket-binding-group ref="eap6-standard-sockets"/>
  </server-group>
</server-groups>

/profile=eap6-default/subsystem=bean-validation:remove

/profile=eap6-default/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true)
/profile=eap6-default/subsystem=weld:write-attribute(name=non-portable-mode,value=true)

/profile=eap6-default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=statistics-enabled,value=true)

<servers>
    <server name="server-one" group="eap6-main-server-group"/>
    <server name="server-two" group="eap6-main-server-group">
        <socket-bindings port-offset="150"/>
    </server>
</servers>

/host-exclude=EAP64z:write-attribute(name=active-server-groups,value=[eap6-main-server-group])

A JBoss EAP 7.3 domain controller can manage hosts and servers running from a previous minor release of JBoss EAP. For a JBoss EAP 7.3 domain controller managing JBoss EAP 7.2 hosts that are on a different patch release, you do not need to make any configuration changes. However, you must run the JBoss EAP 7.2 domain controller on a patch release that is equal to or higher than the versions on the host controllers that it manages. Complete the following tasks to successfully manage JBoss EAP 7.2 instances in a JBoss EAP 7.3 managed domain. Add the JBoss EAP 7.2 configuration to the JBoss EAP 7.3 domain controller . Set the server group for the JBoss EAP 7.2 servers . Prevent the JBoss EAP 7.2 instances from receiving JBoss EAP 7.3 updates . After you complete these tasks, you can manage your JBoss EAP 7.2 servers and configurations from the JBoss EAP 7.3 domain controller using the management CLI.

<servers>
    <server name="server-one" group="eap72-main-server-group"/>
    <server name="server-two" group="eap72-main-server-group">
        <socket-bindings port-offset="150"/>
    </server>
</servers>

<domain-controller>
    <remote security-realm="ManagementRealm" ignore-unused-configuration="true">
        <discovery-options>
            <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
    </remote>
</domain-controller>

JBoss EAP uses profiles as a way to organize which subsystems are available to a server. A profile consists of a collection of available subsystems along with each subsystem’s specific configuration. A profile with a large number of subsystems results in a server with a large set of capabilities. A profile with a small, focused set of subsystems will have fewer capabilities but a smaller footprint. JBoss EAP comes with five predefined profiles that should satisfy most use cases:

JBoss EAP allows you to create a new profile in a managed domain by cloning an existing profile. This will create a copy of the original profile’s configuration and subsystems. A profile can be cloned using the management CLI by using the clone operation on the desired profile to clone.

/profile=full-ha:clone(to-profile=cloned-profile)

You can also clone a profile from the management console by selecting the desired profile to clone and clicking Clone .

In a managed domain, you can create a hierarchy of profiles. This allows you to create a base profile with common extensions that other profiles can inherit. The managed domain defines several profiles in domain.xml . If multiple profiles use the same configuration for a particular subsystem, you can configure it in just one place instead of different profiles. The values in parent profiles cannot be overridden. In addition, each profile must be self-sufficient. If an element or subsystem is referenced, then it must be defined in the profile where it is referenced. A profile can include other profiles in a hierarchy using the management CLI by using the list-add operation and providing the profile to include.

/profile=new-profile:list-add(name=includes, value=PROFILE_NAME)

You can define JVM settings on a host controller, and apply those settings to server groups or individual servers. JBoss EAP comes with a default JVM setting, but the following management CLI command demonstrates creating a new JVM setting named production_jvm with some custom JVM settings and options.

/host=HOST_NAME/jvm=production_jvm:add(heap-size=2048m, max-heap-size=2048m, max-permgen-size=512m, stack-size=1024k, jvm-options=["-XX:-UseParallelGC"])

See Managed Domain JVM Configuration Attributes for descriptions of all available options. You can also create and edit JVM settings in the JBoss EAP management console by navigating to Runtime → Hosts , choosing a host and clicking View , and selecting the JVMs tab. These settings are stored in the within the <jvm> tag in host.xml .

When creating a server group, you can specify a JVM configuration that all servers in the group will use. The following management CLI commands demonstrate creating a server group name groupA that uses the production_jvm JVM settings that were shown in the previous example .

/server-group=groupA:add(profile=default, socket-binding-group=standard-sockets)
/server-group=groupA/jvm=production_jvm:add

All servers in the server group will inherit JVM settings from production_jvm . You can also override specific JVM settings at the server group level. For example, to set a different heap size, you can use the following command:

/server-group=groupA/jvm=production_jvm:write-attribute(name=heap-size,value="1024m")

After applying the above command, the server group groupA will inherit the JVM settings from production_jvm , except for the heap size which has an overridden value of 1024m . See Managed Domain JVM Configuration Attributes for descriptions of all available options. You can also edit server group JVM settings in the JBoss EAP management console by navigating to Runtime → Server Groups , choosing a server group and clicking View , and selecting the JVMs tab. These settings for a server group are stored in domain.xml .

By default, an individual JBoss EAP server instance will inherit the JVM settings of the server group it belongs to. However, you can choose to override the inherited settings with another complete JVM setting definition from the host controller, or choose to override specific JVM settings. For example, the following command overrides the JVM definition of the server group in the previous example , and sets the JVM settings for server-one to the default JVM definition:

/host=HOST_NAME/server-config=server-one/jvm=default:add

Also, similar to server groups, you can override specific JVM settings at the server level. For example, to set a different heap size, you can use the following command:

/host=HOST_NAME/server-config=server-one/jvm=default:write-attribute(name=heap-size,value="1024m")

See Managed Domain JVM Configuration Attributes for descriptions of all available options. You can also edit server JVM settings in the JBoss EAP management console by navigating to Runtime → Hosts , choosing the host, clicking View on the server, and selecting the JVMs tab. These settings for an individual server are stored in host.xml .

By default, all JBoss EAP log entries are written to the server.log file. The location of this file depends on your operating mode. Standalone server: EAP_HOME /standalone/log/server.log Managed domain: EAP_HOME /domain/servers/ SERVER_NAME /log/server.log This file is often referred to as the server log. For more information, see the Root Logger section.

During bootup, JBoss EAP logs information about the Java environment and the startup of each service. This log can be useful when troubleshooting. By default, all log entries are written to the server log . Bootup logging configuration is specified in the logging.properties configuration file, which is active until the JBoss EAP logging subsystem is started and takes over. The location of this file depends on your operating mode. Standalone server: EAP_HOME /standalone/configuration/logging.properties Managed domain: There is a logging.properties file for the domain controller and for each server. Domain controller: EAP_HOME /domain/configuration/logging.properties Server: EAP_HOME /domain/servers/ SERVER_NAME /data/logging.properties

2016-03-16 14:32:01,627 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
        at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.BindException: Address already in use
        ...

/core-service=management:read-boot-errors

Garbage collection logging logs all garbage collection activity to plain text log files. These log files can be useful for diagnostic purposes. Garbage collection logging is enabled by default for a JBoss EAP standalone server on all supported configurations except IBM Java development kit. The location of the garbage collection log is EAP_HOME /standalone/log/gc.log.DIGIT.current . Garbage collection logs are limited to 3 MB each, and up to five files are rotated. It is strongly recommended to leave garbage collection logging enabled as it can be useful in troubleshooting and should have minimal overhead. However, you can disable garbage collection logging for a standalone server by setting the GC_LOG variable to false before starting the server. For example:

$ export GC_LOG=false
$ EAP_HOME/bin/standalone.sh

The following log files are created for the default logging configurations. The default configuration writes the server log files using periodic log handlers.

You can configure the default locale for JBoss EAP by setting JVM properties in the appropriate startup configuration file. The startup configuration file is EAP_HOME /bin/standalone.conf for a standalone server or EAP_HOME /bin/domain.conf for a managed domain. For Windows Server, the JBoss EAP startup configuration files are standalone.conf.bat and domain.conf.bat . Log messages that have been internationalized and localized will use this default locale. See the JBoss EAP Development Guide for information on creating internationalized log messages .

Set the Language

Specify the language by setting the user.language property using the JAVA_OPTS variable. For example, add the following line to the startup configuration file to set a French locale.

JAVA_OPTS="$JAVA_OPTS -Duser.language=fr"

Log messages that have been internationalized and localized will now output in French.

Set the Language and Country

In addition to the language, it may also be necessary to specify the country by setting the user.country property. For example, add the following line to the startup configuration file to set the Portuguese locale for Brazil.

JAVA_OPTS="$JAVA_OPTS -Duser.language=pt -Duser.country=BR"

Log messages that have been internationalized and localized will now output in Brazilian Portuguese.

Set the Server Locale Using the org.jboss.logging.locale Property

You can configure the org.jboss.logging.locale property to override the locale for messages logged using JBoss Logging, including any messages from JBoss EAP and its owned dependencies. Other dependencies, such as JSF, cannot get an overridden locale. To start the JBoss EAP server with a different locale than the system default, you can edit EAP_HOME /bin/standalone.conf or the EAP_HOME /bin/domain.conf file, depending on your operating mode, and append the following command to set the JVM parameter for the required locale. The value of the property must be specified in the BCP 47 format. For example, to set Brazilian Portuguese, use pt-BR.

JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.logging.locale=pt-BR"

The JBoss EAP root logger captures all log messages, of the specified log level or higher, sent to the server that are not captured by a log category. By default, the root logger is configured to use a console and a periodic log handler. The periodic log handler is configured to write to the server.log file. This file is often referred to as the server log. See Configuring the Root Logger for more information.

A log category defines a set of log messages to capture and one or more log handlers that will process the messages. The log messages to capture are defined by the specified Java package of origin and log level. Messages from classes in that package and of that log level or higher are captured by the log category and sent to the specified log handlers. Although the log category is typically the Java package and class name, it can be any name specified by the Logger.getLogger( LOGGER_NAME ) method. Log categories can optionally use the log handlers of the root logger instead of their own handlers. See Configuring Log Categories for more information.

Log handlers define how captured log messages are recorded. The available log handler types are console , file , periodic , size , periodic size , syslog , custom , and async . A log handler must be added to at least one logger in order to be active.

Log Handler Types

A log level is an enumerated value that indicates the nature and severity of a log message. As a developer, you can specify the level of a given log message using the appropriate method of your chosen logging framework to send the message. JBoss EAP supports all the log levels used by the supported application logging frameworks. The most commonly used log levels from lowest to highest are TRACE , DEBUG , INFO , WARN , ERROR , and FATAL . Log levels are used by log categories and handlers to limit the messages they are responsible for. Each log level has an assigned numeric value that indicates its order relative to other log levels. Log categories and handlers are assigned a log level, and they only process log messages of that level or higher. For example a log handler with the level of WARN will only record messages of the levels WARN , ERROR , and FATAL .

Supported Log Levels

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"WFLY\"\,\"YLFW\")")

/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

/subsystem=logging/logger=LOG_CATEGORY:add

/subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=level,value=LEVEL)

/subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=use-parent-handlers,value=USE_PARENT_HANDLERS)

/subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/logger=LOG_CATEGORY:add-handler(name=LOG_HANDLER_NAME)

/subsystem=logging/logger=LOG_CATEGORY:remove

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:add

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=target,value=TARGET)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=CONSOLE_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=CONSOLE_HANDLER_NAME)

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:remove

/subsystem=logging/file-handler=FILE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=append,value=APPEND)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=FILE_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=FILE_HANDLER_NAME)

/subsystem=logging/file-handler=FILE_HANDLER_NAME:remove

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=append,value=APPEND)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_HANDLER_NAME)

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:remove

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=suffix, value=SUFFIX)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=SIZE_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=SIZE_HANDLER_NAME)

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:remove

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:remove

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:add

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=app-name,value=APP_NAME)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=server-address,value=SERVER_ADDRESS)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=port,value=PORT)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=syslog-format,value=SYSLOG_FORMAT)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=named-formatter, value=FORMATTER_NAME)

/subsystem=logging/root-logger=ROOT:add-handler(name=SYSLOG_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=SYSLOG_HANDLER_NAME)

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:remove

/socket-binding-group=SOCKET_BINDING_GROUP/remote-destination-outbound-socket-binding=SOCKET_BINDING_NAME:add(host=HOST, port=PORT)

/subsystem=logging/json-formatter=FORMATTER:add

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:add(outbound-socket-binding-ref=SOCKET_BINDING_NAME,named-formatter=FORMATTER)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=protocol,value=PROTOCOL)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=SOCKET_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=SOCKET_HANDLER_NAME)

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:remove

/subsystem=elytron/key-store=log-server-ks:add(path=/path/to/keystore.jks, type=JKS, credential-reference={clear-text=mypassword})

/subsystem=elytron/trust-manager=log-server-tm:add(key-store=log-server-ks)

/subsystem=elytron/client-ssl-context=log-server-context:add(trust-manager=log-server-tm, protocols=["TLSv1.2"])

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=log-server:add(host=localhost, port=4560)

/subsystem=logging/json-formatter=json:add

/subsystem=logging/socket-handler=log-server-handler:add(named-formatter=json, level=INFO, outbound-socket-binding-ref=log-server, protocol=SSL_TCP, ssl-context=log-server-context)

/subsystem=logging/root-logger=ROOT:add-handler(name=log-server-handler)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:add(class=CLASS_NAME,module=MODULE_NAME)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=CUSTOM_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=CUSTOM_HANDLER_NAME)

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:remove

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add(queue-length=QUEUE_LENGTH)

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add-handler(name=HANDLER_NAME)

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=overflow-action,value=OVERFLOW_ACTION)

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

/subsystem=logging/root-logger=ROOT:add-handler(name=ASYNC_HANDLER_NAME)

/subsystem=logging/logger=CATEGORY:add-handler(name=ASYNC_HANDLER_NAME)

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:remove

/subsystem=logging/root-logger=ROOT:add-handler(name=LOG_HANDLER_NAME)

/subsystem=logging/root-logger=ROOT:remove-handler(name=LOG_HANDLER_NAME)

/subsystem=logging/root-logger=ROOT:write-attribute(name=level,value=LEVEL)

/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:add(pattern=PATTERN)

2016-03-18 15:49:32,075 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:write-attribute(name=color-map,value="LEVEL:COLOR,LEVEL:COLOR")

/subsystem=logging/json-formatter=JSON_FORMATTER_NAME:add(pretty-print=true, exception-output-type=formatted)

/subsystem=logging/json-formatter=logstash:add(exception-output-type=formatted, key-overrides=[timestamp="@timestamp"], meta-data=[@version=1])

/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, exception-output-type=detailed-and-formatted)

<record>
    <timestamp>2018-10-18T13:55:53.419-04:00</timestamp>
    <sequence>62</sequence>
    <loggerClassName>org.jboss.as.server.logging.ServerLogger_$logger</loggerClassName>
    <loggerName>org.jboss.as</loggerName>
    <level>INFO</level>
    <message>WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.0.0.Final-redhat-20190924) started in 6271ms - Started 495 of 679 services (331 services are lazy, passive or on-demand)</message>
    <threadName>Controller Boot Thread</threadName>
    <threadId>22</threadId>
    <ndc></ndc>
    <hostName>localhost.localdomain</hostName>
    <processName>jboss-modules.jar</processName>
    <processId>7790</processId>
</record>

/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, print-namespace=true, namespace-uri="urn:custom:1.0", key-overrides={message=msg, record=logRecord, timestamp=date}, print-details=true)

/subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:add(class=CLASS_NAME, module=MODULE_NAME)

/subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)

/subsystem=logging/periodic-rotating-file-handler=FILE_HANDLER_NAME:write-attribute(name=named-formatter, value=CUSTOM_FORMATTER_NAME)

/subsystem=logging/custom-formatter=custom-xml-formatter:add(class=java.util.logging.XMLFormatter, module=org.jboss.logmanager)
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=custom-xml-formatter)

<record>
  <date>2016-03-23T12:58:13</date>
  <millis>1458752293091</millis>
  <sequence>93963</sequence>
  <logger>org.jboss.as</logger>
  <level>INFO</level>
  <class>org.jboss.as.server.BootstrapListener</class>
  <method>logAdminConsole</method>
  <thread>22</thread>
  <message>WFLYSRV0051: Admin console listening on http://%s:%d</message>
  <param>127.0.0.1</param>
  <param>9990</param>
</record>

/subsystem=logging:write-attribute(name=use-deployment-logging-config,value=false)

/subsystem=logging/logging-profile=PROFILE_NAME:add

/subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:add(file={path=>"LOG_NAME.log", "relative-to"=>"jboss.server.log.dir"})

/subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:write-attribute(name="level", value="DEBUG")

/subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add(level=TRACE)

/subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add-handler(name="FILE_HANDLER_NAME")

/subsystem=logging/logging-profile=accounts-app-profile:add
/subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:add(file={path=>"ejb-trace.log", "relative-to"=>"jboss.server.log.dir"})
/subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:write-attribute(name="level", value="DEBUG")
/subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add(level=TRACE)
/subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add-handler(name="ejb-trace-file")

<logging-profiles>
   <logging-profile name="accounts-app-profile">
      <file-handler name="ejb-trace-file">
         <level name="DEBUG"/>
         <file relative-to="jboss.server.log.dir" path="ejb-trace.log"/>
      </file-handler>
      <logger category="com.company.accounts.ejbs">
         <level name="TRACE"/>
         <handlers>
            <handler name="ejb-trace-file"/>
         </handlers>
      </logger>
   </logging-profile>
</logging-profiles>

Manifest-Version: 1.0
Logging-Profile: accounts-app-profile

/deployment=DEPLOYMENT_NAME/subsystem=logging/configuration=CONFIG:read-resource

/deployment=mydeployment.war/subsystem=logging/configuration=profile-MYPROFILE:read-resource(recursive=true,include-runtime=true)

/deployment=DEPLOYMENT_NAME/subsystem=logging:read-resource(include-runtime=true, recursive=true)

$ EAP_HOME/bin/jboss-cli.sh

module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES

module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javaee.api,sun.jdk,ibm.jdk,javax.api,javax.transaction.api

/subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)

/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.cj.jdbc.Driver)

deploy PATH_TO_JDBC_JAR

deploy /path/to/mysql-connector-java-8.0.12.jar

WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-8.0.12.jar

com.mysql.cj.jdbc.Driver

jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver

import java.sql.Connection;
Connection c = ds.getConnection();
if (c.isWrapperFor(com.mysql.jdbc.Connection.class)) {
    com.mysql.jdbc.Connection mc = c.unwrap(com.mysql.jdbc.Connection.class);
}

data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL

xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS --xa-datasource-properties={"ServerName"=>"HOST_NAME","DatabaseName"=>"DATABASE_NAME"}

/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOST_NAME)

/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)

data-source --name=DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE

xa-data-source --name=XA_DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE

/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=PROPERTY:add(value=VALUE)

data-source remove --name=DATASOURCE_NAME

xa-data-source remove --name=XA_DATASOURCE_NAME

/subsystem=datasources/data-source=DATASOURCE_NAME:test-connection-in-pool

/subsystem=datasources/data-source=DATASOURCE_NAME:flush-all-connection-in-pool

/subsystem=datasources/data-source=DATASOURCE_NAME:flush-gracefully-connection-in-pool

/subsystem=datasources/data-source=DATASOURCE_NAME:flush-idle-connection-in-pool

/subsystem=datasources/data-source=DATASOURCE_NAME:flush-invalid-connection-in-pool

/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=no-recovery,value=true)