Procedure 2.1. Start the Platform Service as a Standalone Server

1. For Red Hat Enterprise Linux.

   Run the command: EAP_HOME/bin/standalone.sh

2. For Microsoft Windows Server.

   Run the command: EAP_HOME\bin\standalone.bat

3. Optional: Specify additional parameters.

   To print a list of additional parameters to pass to the start-up scripts, use the -h parameter.

Procedure 2.2. Start the Platform Service as a Managed Domain

1. For Red Hat Enterprise Linux.

   Run the command: EAP_HOME/bin/domain.sh

2. For Microsoft Windows Server.

   Run the command: EAP_HOME\bin\domain.bat

3. Optional: Pass additional parameters to the start-up script.

   For a list of parameters you can pass to the start-up script, use the -h parameter.

Procedure 2.3. Configure the Host Name Using a System Property

1. Open the host configuration file for editing, for example, host.xml.
2. Find the host element in the file, for example:

   <host name="master" xmlns="urn:jboss:domain:1.6">

3. If it is present, remove the name="HOST_NAME" attribute declaration. The host element should now look like the following example.

   <host xmlns="urn:jboss:domain:1.6">

4. Start the server passing the -Djboss.host.name argument, for example:

   -Djboss.host.name=HOST_NAME

Procedure 2.4. Configure the Host Name Using a Specific Name

1. Start the JBoss EAP slave host using the following syntax:

   bin/domain.sh --host-config=HOST_FILE_NAME

   For example:

   bin/domain.sh --host-config=host-slave01.xml

2. Launch the Management CLI.
3. Use the following syntax to replace the host name:

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

   For example:

   /host=master:write-attribute(name="name",value="host-slave01")

   You should see the following result.

    "outcome" => "success"

   This modifies the host name attribute in the host-slave01.xml file as follows:

   <host name="host-slave01" xmlns="urn:jboss:domain:1.6">

4. You must reload the server configuration using the old host name to complete the process

   reload --host=EXISTING_HOST_NAME

   For example:

   reload --host=master

Procedure 2.5. Create managed domain on two machines

1. On Machine 1

   1. Use the add-user.sh script to add management user. For example, slave01, so the host can authenticate the domain controller. Note the SECRET_VALUE from the add-user output.
   2. Start domain with host-master.xml config file, which is preconfigured for dedicated domain controller.
   3. Use -bmanagement=$IP1 to make domain controller visible to other machines.

      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-master.xml -bmanagement=$IP1

2. On Machine 2

   1. Update $JBOSS_HOME/domain/configuration/host-slave.xml file with user credentials.

      	<?xml version='1.0' encoding='UTF-8'?>
              <host xmlns="urn:jboss:domain:1.6" name="slave01">   
              <!-- add user name here -->
               <management>
                  <security-realms>
                     <security-realm name="ManagementRealm">
                        <server-identities>
                          <secret value="$SECRET_VALUE" />   
                          <!-- use secret value from add-user.sh output-->
                        </server-identities> 
                        ...

   2. Start host.

      [$JBOSS_HOME/bin]$ ./domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=$IP1 -b=$IP2

3. Now we can manage the domain.

   via CLI:

   [$JBOSS_HOME/bin]$ ./jboss-cli.sh -c --controller=$IP1
   

   via Web Console:

   http://$IP1:9990
   

   Access the server index page:

   http://$IP2:8080/
   http://$IP2:8230/
   

Procedure 2.6. Start the Instance with an Alternative Configuration

1. Standalone server

   For a Standalone Server, provide the filename of the configuration file as an option to the --server-config parameter. The configuration file must be located in the EAP_HOME/standalone/configuration/ directory, and you need to specify the file path relative to that directory.

   Example 2.1. Using an alternate configuration file for a Standalone Server in Red Hat Enterprise Linux

   [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml

   This example uses the EAP_HOME/standalone/configuration/standalone-alternate.xml configuration file.

   Example 2.2. Using an alternate configuration file for a Standalone Server in Microsoft Windows Server

   C:\EAP_HOME\bin> standalone.bat --server-config=standalone-alternate.xml

   This example uses the EAP_HOME\standalone\configuration\standalone-alternative.xml configuration file.

2. Managed Domain

   For a Managed Domain, provide the file name of the configuration file as an option to the --domain-config parameter. The file must be present in the EAP_HOME/domain/configuration/ directory, and you need to specify the path relative to that directory.

   Example 2.3. Using an alternate configuration file for a Managed Domain in Red Hat Enterprise Linux

   [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml

   This example uses the EAP_HOME/domain/configuration/domain-alternate.xml configuration file.

   Example 2.4. Using an alternate configuration file for a Managed Domain in Microsoft Windows Server

   C:\EAP_HOME\bin> domain.bat --domain-config=domain-alternate.xml
   
   

   This example uses the EAP_HOME\domain\configuration\domain-alternate.xml configuration file.

Procedure 2.10. Start the Server for a Managed Domain

1. Select the Runtime tab at the top of the console. Expand the Server menu and select Overview.
2. From the list of Server Instances, select the server you want to start. Servers that are running are indicated by a check mark.
   Hover the cursor over an instance in this list to show options in blue text below the server's details.
3. To start the instance, click on the Start Server text when it appears. A confirmation dialogue box will open. Click Confirm to start the server.

Procedure 2.11. Stop a Server in a Managed Domain Using the Management Console

1. Select the Runtime tab from the top of the console. Expand the Domain menu and select Overview.
2. A list of available Server Instances is displayed on the Hosts, groups and server instances table. Servers that are running are indicated by a check mark.
3. Hover the cursor over the chosen server. Click on the Stop Server text that appears. A confirmation dialogue window will appear.
4. Click Confirm to stop the server.

Procedure 2.12. jboss-descriptor-property-replacement

1. In the Management CLI, run the following command to determine the value of jboss-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")

2. Run the following command to configure the behavior:

   /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Procedure 2.13. spec-descriptor-property-replacement

1. In the Management CLI, run the following command to confirm the value of spec-descriptor-property-replacement:

   /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")

2. Run the following command to configure the behavior:

   /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

1. Identify the backed up version that you want to start. This example will recall the instance of the server model prior to the first modification after successfully booting up.

   EAP_HOME/standalone/configuration/standalone_xml_history/current/standalone.v1.xml

2. Start the server with this configuration of the backed up model by passing in the relative filename under jboss.server.config.dir.

   EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml

Procedure 2.14. Take a Configuration Snapshot and Save It

• Save a snapshot

  Run the take-snapshot operation to capture a copy of the current server configuration.

  [standalone@localhost:9999 /] :take-snapshot
  {
      "outcome" => "success",
      "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
  

Procedure 2.15. Load a Configuration Snapshot

1. Identify the snapshot to be loaded. This example will recall the following file from the snapshot directory. The default path for the snapshot files is as follows.

   EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml

   The snapshots are expressed by their relative paths, by which the above example can be written as follows.

   jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml

2. Start the server with the selected configuration snapshot by passing in the filename.

   EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml

Procedure 2.16. Delete a Specific Snapshot

1. Identify the snapshot to be deleted. This example will delete the following file from the snapshot directory.

   EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml

2. Run the :delete-snapshot command to delete a specific snapshot, specifying the name of the snapshot as in the example below.

   [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
   {"outcome" => "success"}
   

Procedure 2.17. Delete All Snapshots

• Run the :delete-snapshot(name="all") command to delete all snapshots as in the example below.

  [standalone@localhost:9999 /] :delete-snapshot(name="all")
  {"outcome" => "success"}
  

Procedure 2.18. List All Configuration Snapshots

• List all snapshots

  List all of the saved snapshots by running the :list-snapshots command.

  [standalone@localhost:9999 /] :list-snapshots
  {
      "outcome" => "success",
      "result" => {
          "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
          "names" => [
              "20110818-133719699standalone.xml",
              "20110809-141225039standalone.xml",
              "20110802-152010683standalone.xml",
              "20110808-161118457standalone.xml",
              "20110912-151949212standalone.xml",
              "20110804-162951670standalone.xml"
          ]
      }
  }
  

1. Navigate to the Management Console start page

   Launch your web browser and navigate to the Management Console in your web browser at http://localhost:9990/console/App.html

   Note

   Port 9990 is predefined as the Management Console socket binding.
2. Enter the username and password of the account that you created previously to log in to the Management Console login screen.
   

   Figure 3.1. Log in screen for the Management Console

Procedure 3.1. Change the Language of the Web-based Management Console

1. Log into the Management Console.

   Log into the web-based Management Console.

2. Open the Settings dialog.

   Near the bottom right of the screen is a Settings label. Click it to open the settings for the Management Console.

3. Select the desired language.

   Select the desired language from the Locale selection box. Select Save. A confirmation box informs you that you need to reload the application. Click Confirm. Refresh your web browser to use the new locale.

Procedure 3.2. Configure the Server

1. Select the Domain tab from the top of the console. Available server instances will be displayed in a table.
2. Select the server instance from the Available Server Configurations table.
3. Click Edit above the details of the chosen server.
4. Make changes to the configuration attributes.
5. Click Save to finish.

1. Select the Runtime tab at the top of the console.
2. For a standalone server, expand the Server menu and select Manage Deployments. For a managed domain, expand the Domain menu and select Manage Deployments. The Manage Deployments panel appears.
3. Select Add on the Content Repository tab. A Create Deployment dialog box appears.
4. In the dialog box, click Browse. Browse to the file you want to deploy and select it for upload. Click Next to proceed.
5. Verify the deployment name and runtime name that appear in the Create Deployments dialog box. Click Save to upload the file once the names are verified.

Procedure 3.3. Create a New Server Configuration

1. Navigate to the Server Configurations page in the Management Console

   Select the Domain tab from the top of the console.

2. Create a new configuration

   1. Select the Add button above the Available Server Configuration table.
   2. Enter the basic server settings in the Create Server Configuration dialog.
   3. Select the Save button to save the new server configuration.

Procedure 3.4. Edit the Logging Levels

1. Navigate to the Logging panel in the Management Console

   1. If you are working with a managed domain, select the Configuration tab at the top of the console, then select the relevant profile from the drop-down list on the left of the console.
   2. For either a managed domain or a standalone server, expand the Core menu from the list on the left of the console and click the Logging entry.
   3. Click on the Log Categories tab in the top of the console.

2. Edit logger details

   Edit the details for any of the entries in the Log Categories table.
   1. Select an entry in the Log Categories table, then click Edit in the Details section below.
   2. Set the log level for the category with the Log Level drop-down box. Click the Save button when done.

Procedure 3.5. Configure and Add a new Server Group

1. Navigate to the Server Groups view

   Select the Domain tab from the top of the console.
2. Expand the Server label in the menu in the left hand column. Select Server Groups.

3. Add a server group

   Click the Add button to add a new server group.

4. Configure the server group

   1. Enter a name for the server group.
   2. Select the profile for the server group.
   3. Select the socket binding for the server group.
   4. Click the Save button to save your new group.

Procedure 3.6. Launch CLI in Linux or Microsoft Windows Server

• • Launch the CLI in Linux

    Run the EAP_HOME/bin/jboss-cli.sh file by entering the following at a command line:

    $ EAP_HOME/bin/jboss-cli.sh

  • Launch the CLI in Microsoft Windows Server

    Run the EAP_HOME\bin\jboss-cli.bat file by double-clicking it, or by entering the following at a command line:

    C:\>EAP_HOME\bin\jboss-cli.bat

Procedure 3.7. Connect to a Managed Server Instance

• Run the connect command

  From the Management CLI, enter the connect command:

  [disconnected /] connect
  Connected to domain controller at localhost:9999

  • Alternatively, to connect to a managed server when starting the Management CLI on a Linux system, use the --connect parameter:

    $ EAP_HOME/bin/jboss-cli.sh --connect

  • The --connect parameter can be used to specify the host and port of the server. To connect to the address 192.168.0.1 with the port value 9999 the following would apply:

    $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

1. For general help

   From the Management CLI, enter the help command:

   [standalone@localhost:9999 /] help

2. Obtain context-sensitive help

   From the Management CLI, enter the help -commands extended command:

   [standalone@localhost:9999 /] help --commands

3. For a more detailed description of a specific command, enter the command, followed by --help.

   [standalone@localhost:9999 /] deploy --help

Procedure 3.8. Batch Mode Commands and Operations

1. Enter batch mode

   Enter batch mode with the batch command.

   [standalone@localhost:9999 /] batch
   [standalone@localhost:9999 / #]

   Batch mode is indicated by the hash symbol (#) in the prompt.

2. Add operation requests to the batch

   Once in batch mode, enter operation requests as normal. The operation requests are added to the batch in the order they are entered.
   Refer to Section 3.5.8, “Use Operations and Commands in the Management CLI” for details on formatting operation requests.

3. Run the batch

   Once the entire sequence of operation requests is entered, run the batch with the run-batch command.

   [standalone@localhost:9999 / #] run-batch
   The batch executed successfully.

   Refer to Section 3.5.7, “CLI Batch Mode Commands” for a full list of commands available for working with batches.

4. Batch commands stored in external files

   Frequently run batch commands can be stored in an external text file and can either be loaded by passing the full path to the file as an argument to the batch command or executed directly by being an argument to the run-batch command.
   You can create a batch command file using a text editor. Each command must be on a line by itself and the CLI should be able to access it.
   The following command will load a myscript.txt file in the batch mode. All commands in this file will now be accessible to be edited or removed. New commands can be inserted. Changes made in this batch session do not persist to the myscript.txt file.

   [standalone@localhost:9999 /] batch --file=myscript.txt

   The following will instantly run the batch commands stored in the file myscript.txt

   [standalone@localhost:9999 /] run-batch --file=myscript.txt

Procedure 3.9. Create, Configure and Execute Requests

1. Construct the operation request

   Operation requests allow for low-level interaction with the management model. They provide a controlled way to edit server configurations. An operation request consists of three parts:
   • an address, prefixed with a slash (/).
   • an operation name, prefixed with a colon (:).
   • an optional set of parameters, contained within parentheses (()).

   1. Determine the address

      The configuration is presented as a hierarchical tree of addressable resources. Each resource node offers a different set of operations. The address specifies which resource node to perform the operation on. An address uses the following syntax:

      /node-type=node-name

      • node-type is the resource node type. This maps to an element name in the configuration XML.
      • node-name is the resource node name. This maps to the name attribute of the element in the configuration XML.
      • Separate each level of the resource tree with a slash (/).
      Refer to the configuration XML files to determine the required address. The EAP_HOME/standalone/configuration/standalone.xml file holds the configuration for a standalone server and the EAP_HOME/domain/configuration/domain.xml and EAP_HOME/domain/configuration/host.xml files hold the configuration for a managed domain.

      Example 3.3. Example operation addresses

      To perform an operation on the logging subsystem, use the following address in an operation request:

      /subsystem=logging

      To perform an operation on the Java datasource, use the following address in an operation request:

      /subsystem=datasources/data-source=java

   2. Determine the operation

      Operations differ for each different type of resource node. An operation uses the following syntax:

      :operation-name

      • operation-name is the name of the operation to request.
      Use the read-operation-names operation on any resource address in a standalone server to list the available operations.

      Example 3.4. Available operations

      To list all available operations for the logging subsystem, enter the following request for a standalone server:

      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }

   3. Determine any parameters

      Each operation may require different parameters.
      Parameters use the following syntax:

      (parameter-name=parameter-value)

      • parameter-name is the name of the parameter.
      • parameter-value is the value of the parameter.
      • Multiple parameters are separated by commas (,).
      To determine any required parameters, perform the read-operation-description command on a resource node, passing the operation name as a parameter. Refer to Example 3.5, “Determine operation parameters” for details.

      Example 3.5. Determine operation parameters

      To determine any required parameters for the read-children-types operation on the logging subsystem, enter the read-operation-description command as follows:

      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }

2. Enter the full operation request

   Once the address, operation, and any parameters have been determined, enter the full operation request.

   Example 3.6. Example operation request

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)

Procedure 3.10. Display the Current Runtime Value of a Selected Attribute

• Run the read-attribute operation

  From the Management CLI, use the read-attribute operation to display the value of a resource attribute. For more details on operation requests, refer to the topic Section 3.5.8, “Use Operations and Commands in the Management CLI”.

  [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)

Procedure 3.11. Display the Active User in the Management CLI Using the whoami Operation

• Run the whoami operation

  From the Management CLI, use the whoami operation to display the active user account.

  [standalone@localhost:9999 /] :whoami

  The following example uses the whoami operation in a standalone server instance to show that the active user is username, and that the user is assigned to the ManagementRealm realm.

  Example 3.8. Use the whoami in a standalone instance

  [standalone@localhost:9999 /]:whoami
  {
      "outcome" => "success",
      "result" => {"identity" => {
          "username" => "username",
          "realm" => "ManagementRealm"
      }}
  }
  

Procedure 3.12. Display System and Server Information in the Management CLI

• Run the version command

  From the Management CLI, enter the version command:

  [domain@localhost:9999 /] version

Procedure 3.13. Execute the Command in Management CLI

• Run the read-operation-description operation

  From the Management CLI, use read-operation-description to display information about the operation. The operation requires additional parameters in the format of a key-value pair to indicate which operation to display. For more details on operation requests, refer to the topic Section 3.5.8, “Use Operations and Commands in the Management CLI”.

  [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

Procedure 3.14. Execute the Command in Management CLI

• Run the read-operation-names operation

  From the Management CLI, use the read-operation-names operation to display the names of the available operations. For more details on operation requests, refer to the topic Section 3.5.8, “Use Operations and Commands in the Management CLI”.

  [standalone@localhost:9999 /]:read-operation-names

Procedure 3.15. Execute the Command in Management CLI

1. Run the read-resource operation

   From the Management CLI, use the read-resource operation to display the available resources.

   [standalone@localhost:9999 /]:read-resource

   The following example shows how you might use the read-resource operation on a standalone server instance to expose general resource information. The results resemble the standalone.xml configuration file, displaying the system resources, extensions, interfaces and subsystems installed or configured for the server instance. These can be further queried directly.

   Example 3.11. Using the read-resource operation at the root level

   [standalone@localhost:9999 /]:read-resource
   {
       "outcome" => "success",
       "result" => {
           "deployment" => undefined,
           "deployment-overlay" => undefined,
           "management-major-version" => 1,
           "management-micro-version" => 0,
           "management-minor-version" => 4,
           "name" => "longgrass",
           "namespaces" => [],
           "product-name" => "EAP",
           "product-version" => "6.3.0.GA",
           "release-codename" => "Janus",
           "release-version" => "7.2.0.Final-redhat-3",
           "schema-locations" => [],
           "system-property" => undefined,
           "core-service" => {
               "management" => undefined,
               "service-container" => undefined,
               "server-environment" => undefined,
               "platform-mbean" => undefined
           },
           "extension" => {
               "org.jboss.as.clustering.infinispan" => undefined,
               "org.jboss.as.connector" => undefined,
               "org.jboss.as.deployment-scanner" => undefined,
               "org.jboss.as.ee" => undefined,
               "org.jboss.as.ejb3" => undefined,
               "org.jboss.as.jaxrs" => undefined,
               "org.jboss.as.jdr" => undefined,
               "org.jboss.as.jmx" => undefined,
               "org.jboss.as.jpa" => undefined,
               "org.jboss.as.jsf" => undefined,
               "org.jboss.as.logging" => undefined,
               "org.jboss.as.mail" => undefined,
               "org.jboss.as.naming" => undefined,
               "org.jboss.as.pojo" => undefined,
               "org.jboss.as.remoting" => undefined,
               "org.jboss.as.sar" => undefined,
               "org.jboss.as.security" => undefined,
               "org.jboss.as.threads" => undefined,
               "org.jboss.as.transactions" => undefined,
               "org.jboss.as.web" => undefined,
               "org.jboss.as.webservices" => undefined,
               "org.jboss.as.weld" => undefined
           },
           "interface" => {
               "management" => undefined,
               "public" => undefined,
               "unsecure" => undefined
           },
           "path" => {
               "jboss.server.temp.dir" => undefined,
               "user.home" => undefined,
               "jboss.server.base.dir" => undefined,
               "java.home" => undefined,
               "user.dir" => undefined,
               "jboss.server.data.dir" => undefined,
               "jboss.home.dir" => undefined,
               "jboss.server.log.dir" => undefined,
               "jboss.server.config.dir" => undefined,
               "jboss.controller.temp.dir" => undefined
           },
           "socket-binding-group" => {"standard-sockets" => undefined},
           "subsystem" => {
               "logging" => undefined,
               "datasources" => undefined,
               "deployment-scanner" => undefined,
               "ee" => undefined,
               "ejb3" => undefined,
               "infinispan" => undefined,
               "jaxrs" => undefined,
               "jca" => undefined,
               "jdr" => undefined,
               "jmx" => undefined,
               "jpa" => undefined,
               "jsf" => undefined,
               "mail" => undefined,
               "naming" => undefined,
               "pojo" => undefined,
               "remoting" => undefined,
               "resource-adapters" => undefined,
               "sar" => undefined,
               "security" => undefined,
               "threads" => undefined,
               "transactions" => undefined,
               "web" => undefined,
               "webservices" => undefined,
               "weld" => undefined
           }
       }
   }
   

2. Run the read-resource operation against a child node

   The read-resource operation can be run to query child nodes from the root. The structure of the operation first defines the node to expose, and then appends the operation to run against it.

   [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource

   In the following example, specific resource information about a web subsystem component can be exposed by directing the read-resource operation towards the specific web subsystem node.

   Example 3.12. Expose child node resources from the root node

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
   {
       "outcome" => "success",
       "result" => {
           "configuration" => undefined,
           "enable-lookups" => false,
           "enabled" => true,
           "executor" => undefined,
           "max-connections" => undefined,
           "max-post-size" => 2097152,
           "max-save-post-size" => 4096,
           "name" => "http",
           "protocol" => "HTTP/1.1",
           "proxy-name" => undefined,
           "proxy-port" => undefined,
           "redirect-port" => 443,
           "scheme" => "http",
           "secure" => false,
           "socket-binding" => "http",
           "ssl" => undefined,
           "virtual-server" => undefined
       }
   }
   

   The same results are possible by using the cd command to navigate into the child nodes and run the read-resource operation directly.

   Example 3.13. Expose child node resources by changing directories

   [standalone@localhost:9999 /] cd subsystem=web

   [standalone@localhost:9999 subsystem=web] cd connector=http

   [standalone@localhost:9999 connector=http] :read-resource
   {
       "outcome" => "success",
       "result" => {
           "configuration" => undefined,
           "enable-lookups" => false,
           "enabled" => true,
           "executor" => undefined,
           "max-connections" => undefined,
           "max-post-size" => 2097152,
           "max-save-post-size" => 4096,
           "name" => "http",
           "protocol" => "HTTP/1.1",
           "proxy-name" => undefined,
           "proxy-port" => undefined,
           "redirect-port" => 443,
           "scheme" => "http",
           "secure" => false,
           "socket-binding" => "http",
           "ssl" => undefined,
           "virtual-server" => undefined
       }
   }
   

3. Use the recursive parameter to include active values in results

   The recursive parameter can be used to expose the values of all attributes, including non-persistent values, those passed at startup, or other attributes otherwise active in the runtime model.

   [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)

   Compared to the previous example, the inclusion of the include-runtime request property exposes additional active attributes, such as the bytes sent and bytes received by the HTTP connector.

   Example 3.14. Expose additional and active values with the include-runtime parameter

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
   {
       "outcome" => "success",
       "result" => {
           "any" => undefined,
           "any-address" => undefined,
           "any-ipv4-address" => undefined,
           "any-ipv6-address" => undefined,
           "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
           "link-local-address" => undefined,
           "loopback" => undefined,
           "loopback-address" => undefined,
           "multicast" => undefined,
           "name" => "public",
           "nic" => undefined,
           "nic-match" => undefined,
           "not" => undefined,
           "point-to-point" => undefined,
           "public-address" => undefined,
           "resolved-address" => "127.0.0.1",
           "site-local-address" => undefined,
           "subnet-match" => undefined,
           "up" => undefined,
           "virtual" => undefined
       }
   }
   

Procedure 3.16. Execute the Command in Management CLI

1. Run the read-resource-description operation

   From the Management CLI, use the read-resource-description operation to read and display the available resources. For more details on operation requests, refer to the topic Section 3.5.8, “Use Operations and Commands in the Management CLI”.

   [standalone@localhost:9999 /]:read-resource-description

2. Use optional parameters

   The read-resource-description operation allows the use of the additional parameters.
   1. Use the operations parameter to include descriptions of the resource's operations.

      [standalone@localhost:9999 /]:read-resource-description(operations=true)

   2. Use the inherited parameter to include or exclude descriptions of the resource's inherited operations. The default state is true.

      [standalone@localhost:9999 /]:read-resource-description(inherited=false)

   3. Use the recursive parameter to include recursive descriptions of the child resources.

      [standalone@localhost:9999 /]:read-resource-description(recursive=true)

   4. Use the locale parameter to get the resource description in. If null, the default locale will be used.

      [standalone@localhost:9999 /]:read-resource-description(locale=true)

Procedure 3.17. Shut down the Application Server

• Run the shutdown operation

  • From the Management CLI, use the shutdown operation to shut the server down via the System.exit(0) system call. For more details on operation requests, refer to the topic Section 3.5.8, “Use Operations and Commands in the Management CLI”.
    • In the standalone mode, use the following command:

      [standalone@localhost:9999 /]:shutdown

    • In the domain mode, use the following command with the appropriate host name:

      [domain@localhost:9999 /]/host=master:shutdown

  • To connect to a detached CLI instance and shut down the server, execute the following command:

    jboss-cli.sh --connect command=:shutdown
    

  • To connect to a remote CLI instance and shut down the server, execute the following command:

    [disconnected /] connect IP_ADDRESS
    Connected to IP_ADDRESS:PORT_NUMBER
    [192.168.1.10:9999 /] :shutdown
    

    Replace IP_ADDRESS with the IP address of your instance.

Procedure 3.18. Configure a Resource Attribute with the Management CLI

• Run the write-attribute operation

  From the Management CLI, use the write-attribute operation to modify the value of a resource attribute. The operation can be run at the child node of the resource or at the root node of the Management CLI where the full resource path is specified.

Procedure 3.19. Configure System Properties Using the Management CLI

1. Start the JBoss EAP server.
2. Launch the Management CLI using the command for your operating system.
   For Linux:

   EAP_HOME/bin/jboss-cli.sh --connect

   For Windows:

   EAP_HOME\bin\jboss-cli.bat --connect

3. Add a system property.
   The command you use depends on whether you are running a standalone server or a managed domain. If you are running a managed domain, you can add system properties to any or all of the servers running in that domain.
   • Add a system property on a standalone server using the following syntax:

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Example 3.17. Add a system property to a standalone server

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {"outcome" => "success"}

   • Add a system property to all hosts and servers in a managed domain using the following syntax:

     /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Example 3.18. Add a system property to all servers in a managed domain

     [domain@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }

   • Add a system property to a host and its server instances in a managed domain using the following syntax:

     /host=master/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Example 3.19. Add a system property to a host and its servers in a domain

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }

   • Add a system property to a server instance in a managed domain using the following syntax:

     /host=master/server-config=server-one/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

     Example 3.20. Add a system property to a server instance in a managed domain

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
     }
     

4. Read a system property.
   The command you use depends on whether you are running a standalone server or a managed domain.
   • Read a system property from a standalone server using the following syntax:

     /system-property=PROPERTY_NAME:read-resource

     Example 3.21. Read a system property from a standalone server

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {"value" => "java:/queue/MyBeanQueue"}
     }
     

   • Read a system property from all hosts and servers in a managed domain using the following syntax:

     /system-property=PROPERTY_NAME:read-resource

     Example 3.22. Read a system property from all servers in a managed domain

     [domain@localhost:9999 /] /system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }

   • Read a system property from a host and its server instances in a managed domain using the following syntax:

     /host=master/system-property=PROPERTY_NAME:read-resource

     Example 3.23. Read a system property from a host and its servers in a domain

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }
     

   • Read a system property from a server instance in a managed domain using the following syntax:

     /host=master/server-config=server-one/system-property=PROPERTY_NAME:read-resource

     Example 3.24. Read a system property from a server instance in a managed domain

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:read-resource
     {
         "outcome" => "success",
         "result" => {
             "boot-time" => true,
             "value" => "java:/queue/MyBeanQueue"
         }
     }

5. Remove a system property.
   The command you use depends on whether you are running a standalone server or a managed domain.
   • Remove a system property from a standalone server using the following syntax:

     /system-property=PROPERTY_NAME:remove

     Example 3.25. Remove a system property from a standalone server

     [standalone@localhost:9999 /] /system-property=property.mybean.queue:remove
     {"outcome" => "success"}

   • Remove a system property from all hosts and servers in a managed domain using the following syntax:

     /system-property=PROPERTY_NAME:remove

     Example 3.26. Remove a system property from all hosts and servers in a domain

     [domain@localhost:9999 /] /system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }
     

   • Remove a system property from a host and its server instances in a managed domain using the following syntax:

     /host=master/system-property=PROPERTY_NAME:remove

     Example 3.27. Remove a system property from a host and its instances in a domain

     [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {
             "server-one" => {"response" => {"outcome" => "success"}},
             "server-two" => {"response" => {"outcome" => "success"}}
         }}}}
     }
     

   • Remove a system property from a server instance in a managed domain using the following syntax:

     /host=master/server-config=server-one/system-property=PROPERTY_NAME:remove

     Example 3.28. Remove a system property from a server in a managed domain

     [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:remove
     {
         "outcome" => "success",
         "result" => undefined,
         "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
     }
     

Procedure 3.20. Show the Management CLI Command History

• Run the history command

  From the Management CLI, enter the history command:

  [standalone@localhost:9999 /] history

Procedure 3.21. Clear the Management CLI Command history

• Run the history --clear command

  From the Management CLI, enter the history --clear command:

  [standalone@localhost:9999 /] history --clear

Procedure 3.22. Disable the Management CLI Command history

• Run the history --disable command

  From the Management CLI, enter the history --disable command:

  [standalone@localhost:9999 /] history --disable

Procedure 3.23. Enable the Management CLI Command history

• Run the history --enable command

  From the Management CLI, enter the history --enable command:

  [standalone@localhost:9999 /] history --enable

Procedure 3.24. Enable Logging to a Syslog Server

1. Create a syslog handler named msyslog

   [standalone@localhost:9999 /]batch
   [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
   [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
   [standalone@localhost:9999 /]run-batch

2. Add a reference to the syslog handler.

   [standalone@localhost:9999 /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add

Procedure 4.1. Create the Initial Administrative User for the Remote Management Interfaces

1. Run the add-user.sh or add-user.bat script.

   Change to the EAP_HOME/bin/ directory. Invoke the appropriate script for your operating system.

   Red Hat Enterprise Linux

   [user@host bin]$ ./add-user.sh

   Microsoft Windows Server

   C:\bin>  add-user.bat

2. Choose to add a Management user.

   Press ENTER to select the default option a to add a Management user.
   This user is added to the ManagementRealm and is authorized to perform management operations using the web-based Management Console or command-line based Management CLI. The other choice, b, adds a user to the ApplicationRealm, and provides no particular permissions. That realm is provided for use with applications.

3. Enter the desired username and password.

   When prompted, enter the username and password. You will be prompted to confirm the password.

4. Enter group information.

   Add the group or groups to which the user belongs. If the user belongs to multiple groups, enter a comma-separated list. Leave it blank if you do not want the user to belong to any groups.

5. Review the information and confirm.

   You are prompted to confirm the information. If you are satisfied, type yes.

6. Choose whether the user represents a remote JBoss EAP 6 server instance.

   Besides administrators, the other type of user which occasionally needs to be added to JBoss EAP 6 in the ManagementRealm is a user representing another instance of JBoss EAP 6, which must be able to authenticate to join a cluster as a member. The next prompt allows you to designate your added user for this purpose. If you select yes, you will be given a hashed secret value, representing the user's password, which would need to be added to a different configuration file. For the purposes of this task, answer no to this question.

7. Enter additional users.

   You can enter additional users if desired, by repeating the procedure. You can also add them at any time on a running system. Instead of choosing the default security realm, you can add users to other realms to fine-tune their authorizations.

8. Create users non-interactively.

   You can create users non-interactively, by passing in each parameter at the command line. This approach is not recommended on shared systems, because the passwords will be visible in log and history files. The syntax for the command, using the management realm, is:

   [user@host bin]$ ./add-user.sh username password

   To use the application realm, use the -a parameter.

   [user@host bin]$ ./add-user.sh -a username password

9. You can suppress the normal output of the add-user script by passing the --silent parameter. This applies only if the minimum parameters username and password have been specified. Error messages will still be shown.

Procedure 4.2. Specify Alternate Properties Files

• • To specify an alternate directory for the server configuration, use the -sc argument. This argument specifies an alternate directory that will contain the server configuration properties files.
  • To specify an alternate directory for the domain configuration, use the -dc argument. This argument specifies an alternate directory that will contain the domain configuration properties files.
  • To specify an alternate user configuration properties file, use the -up or --user-properties argument. It can be an absolute path or it can be a file name used in conjunction with the -sc or -dc argument that specifies the alternate configuration directory.
  • To specify an alternate group configuration properties file, use the -gp or --group-properties argument. It can be an absolute path or it can be a file name used in conjunction with the -sc or -dc argument that specifies the alternate configuration directory.

• Configure Interface Attributes

  You can use tab completion to complete the command string as you type, as well as to expose the available attributes.

  • Configure Interface Attributes with the Management CLI

    Use the Management CLI to add new interfaces and write new values to the interface attributes.

    1. Add a New Interface

       The add operation creates new interfaces as required. The add command runs from the root of the Management CLI session, and in the following example it creates a new interface name title interfacename, with an inet-address declared as 12.0.0.2.

       /interface=interfacename/:add(inet-address=12.0.0.2)

    2. Edit Interface Attributes

       The write-attribute operation writes new values to an attribute. The following example updates the inet-address value to 12.0.0.8.

       /interface=interfacename/:write-attribute(name=inet-address, value=12.0.0.8)

    3. Verify Interface Attributes

       Confirm that the attribute values have changed by running the read-resource operation with the include-runtime=true parameter to expose all current values active in the server model. For example:

       [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)

  • Configure Interface Attributes with the Management Console

    1. Log into the Management Console.

       Log into the Management Console of your Managed Domain or Standalone Server instance.

    2. Navigate to the Interfaces screen

       1. Navigate to Configuration tab.

          Select the Configuration tab from the top of the screen.

       2. For Domain Mode only

          Select a profile from the Profile drop-down menu at the top left of the screen.

    3. Select Interfaces from the Navigation Menu.

       Expand the General Configuration menu. Select the Interfaces menu item from the navigation menu.

    4. Add a New Interface

       1. Click Add.
       2. Enter any required values for Name, Inet Address and Address Wildcard.
       3. Click Save.

    5. Edit Interface Attributes

       1. Select the interface that you need to edit from the Available Interfaces list and click Edit.
       2. Enter any required values for Name, Inet Address and Address Wildcard.
       3. Click Save.

• Configure Socket Bindings in Socket Binding Groups

  Choose either the management CLI or the management console to configure your socket bindings as required.

  • Configure Socket Bindings Using the Management CLI

    Use the management CLI to configure socket bindings.

    1. Add a New Socket Binding

       Use the add operation to create a new address setting if required. You can run this command from the root of the management CLI session, which in the following examples creates a new socket binding titled newsocket, with a port attribute declared as 1234. The examples apply for both a standalone server and a managed domain editing on the standard-sockets socket binding group as shown.

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)

    2. Edit Pattern Attributes

       Use the write-attribute operation to write a new value to an attribute. You can use tab completion to help complete the command string as you type, as well as to expose the available attributes. The following example updates the port value to 2020

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)

    3. Confirm Pattern Attributes

       Confirm the values are changed by running the read-resource operation with the include-runtime=true parameter to expose all current values active in the server model.

       [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource

  • Configure Socket Bindings Using the Management Console

    Use the management console to configure socket bindings.

    1. Log into the Management Console.

       Log into the management console of your managed domain or standalone server.

    2. Navigate to the Configuration tab.

       Select the Configuration tab at the top of the screen.

    3. Select the Socket Binding item from the navigation menu.

       Expand the General Configuration menu. Select Socket Binding. If you are using a managed domain, select the desired group in the Socket Binding Groups list.

    4. Add a New Socket Binding

       1. Click the Add button.
       2. Enter any required values for Name, Port and Binding Group.
       3. Click Save to finish.

    5. Edit Socket Binding

       1. Select a socket binding from the list and click Edit.
       2. Enter any required values such as Name, Interface or Port.
       3. Click Save to finish.

• Configure Port Offsets

  Choose either the Management CLI or the Management Console to configure your port offsets.

  • Configure Port Offsets Using the Management CLI

    Use the Management CLI to configure port offsets.

    1. Edit Port Offsets

       Use the write-attribute operation to write a new value to the port offset atttribute. The following example updates the socket-binding-port-offset value of server-two to 250. This server is a member of the default local host group. A restart is required for the changes to take effect.

       [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

    2. Confirm Port Offset Attributes

       Confirm the values are changed by running the read-resource operation with the include-runtime=true parameter to expose all current values active in the server model.

       [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)

  • Configure Port Offsets Using the Management Console

    Use the Management Console to configure port offsets.

    1. Log into the Management Console.

       Log into the Management Console of your Managed Domain.

    2. Select the Domain tab

       Select the Domain tab at the top of the screen.

    3. Edit Port Offset Attributes

       1. Select the server under the Available Server Configurations list and click Edit at the top of the attibutes list below.
       2. Enter any desired values in the Port Offset field.
       3. Click Save to finish.

Procedure 5.1. Disable the IPv4 Stack Java Property

1. Open the relevant file for the installation:

   • For a Standalone Server:

     Open EAP_HOME/bin/standalone.conf.

   • For a Managed Domain:

     Open EAP_HOME/bin/domain.conf.
2. Change the IPv4 Stack Java property to false:

   -Djava.net.preferIPv4Stack=false

   For example:

   # Specify options to pass to the Java VM.
   #
   if [ "x$JAVA_OPTS" = "x" ]; then
      JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
      -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
      -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
   fi
   

Procedure 5.2. Configure the Interface for IPv6 Networking

1. Select the Configuration tab at the top of the screen.
2. Expand the General Configuration menu and select Interfaces.
3. Select the interface from the Available Interfaces list.
4. Click Edit in the detail list.
5. Set the inet address to:

   ${jboss.bind.address.management:[ADDRESS]}

6. Click Save to finish.
7. Restart the server to implement the changes.

Procedure 5.3. Configure the JBoss EAP 6 Installation to Prefer IPv6 Addresses

1. Open the relevant file for the installation:

   • For a Standalone Server:

     Open EAP_HOME/bin/standalone.conf.

   • For a Managed Domain:

     Open EAP_HOME/bin/domain.conf.
2. Append the following Java property to the Java VM options:

   -Djava.net.preferIPv6Addresses=true

   For example:

   # Specify options to pass to the Java VM.
   #
   if [ "x$JAVA_OPTS" = "x" ]; then
      JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
      -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
      -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
   fi
   

Procedure 6.1. Modify the JDBC Driver JAR

1. Change to, or create, an empty temporary directory.
2. Create a META-INF subdirectory.
3. Create a META-INF/services subdirectory.
4. Create a META-INF/services/java.sql.Driver file, which contains one line indicating the fully-qualified class name of the JDBC driver.
5. Use the JAR command-line tool to update the JAR like this:

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

6. Section 3.4.2, “Log in to the Management Console”
7. If you use a managed domain, deploy the JAR file to a server group. Otherwise, deploy it to your server. See Section 10.2.2, “Enable a Deployed Application Using the Management Console”.

Procedure 6.2. Install a JDBC Driver as a Core Module

1. Create a file path structure under the EAP_HOME/modules/ directory. For example, for a MySQL JDBC driver, create a directory structure as follows: EAP_HOME/modules/com/mysql/main/.
2. Copy the JDBC driver JAR into the main/ subdirectory.
3. In the main/ subdirectory, create a module.xml file similar to the example in Section 7.1.1, “Modules”. The module XSD is defined in the EAP_HOME/docs/schema/module-1_2.xsd file.
4. Start the Server.
5. Start the Management CLI.
6. Run the CLI command to add the JDBC driver module to the server configuration.
   The command you choose depends on the number of classes listed in the /META-INF/services/java.sql.Driver file located in the JDBC driver JAR. For example, the /META-INF/services/java.sql.Driver file in the MySQL 5.1.20 JDBC JAR lists two classes:

   • com.mysql.jdbc.Driver
   • com.mysql.fabric.jdbc.FabricMySQLDriver

   When there is more than one entry, you must also specify the name of the driver class. Failure to do so results in an error similar to the following:

   JBAS014749: Operation handler failed: Service jboss.jdbc-driver.mysql is already registered

   • Run the CLI command for JDBC JARs containing one class entry.

     /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)

     Example 6.1. Example CLI Command for Standalone Mode for JDBC JARs with one driver class

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

     Example 6.2. Example CLI Command for Domain Mode for JDBC JARs with one driver class

     /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)

   • Run the CLI command for JDBC JARs containing multiple class entries.

     /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)

     Example 6.3. Example CLI Command for Standalone Mode for JDBC JARs with multiple driver class entries

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

     Example 6.4. Example CLI Command for Domain Mode for JDBC JARs with multiple driver class entries

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

Procedure 6.3. Add a Dependency to the Application

• • Configure the MANIFEST.MF file

    1. Open the application's META-INF/MANIFEST.MF file in a text editor.
    2. Add a dependency for the JDBC module and save the file.

       Dependencies: MODULE_NAME

       Example 6.5. Example Dependency

       Dependencies: com.mysql

  • 1. Create a jboss-deployment-structure.xml file

       Create a file called jboss-deployment-structure.xml in the META-INF/ or WEB-INF folder of the application.

       Example 6.6. Example jboss-deployment-structure.xml file

       <jboss-deployment-structure>
         <deployment>
           <dependencies>
             <module name="com.mysql" />
           </dependencies>
         </deployment>
       </jboss-deployment-structure>
       

Procedure 6.4. Create a Datasource using either the Management CLI or the Management Console

• • Management CLI

    1. Launch the CLI tool and connect to your server.
    2. Run the following command to create a non-XA datasource, configuring the variables as appropriate:

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

    3. Enable the datasource:

       data-source enable --name=DATASOURCE_NAME

  • Management Console

    1. Login to the Management Console.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain mode only, select a profile from the drop-down box in the top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources from the menu on the left of the console.

    3. Create a new datasource

       1. Click Add at the top of the Datasources panel.
       2. Enter the new datasource attributes in the Create Datasource wizard and proceed with the Next button.
       3. Enter the JDBC driver details in the Create Datasource wizard and click Next to continue.
       4. Enter the connection settings in the Create Datasource wizard.
       5. Click the Test Connection button to test the connection to the datasource and verify the settings are correct.
       6. Click Done to finish

Procedure 6.5. Modify a Non-XA Datasource

• • Management CLI

    1. Section 3.5.2, “Launch the Management CLI”.
    2. Use the write-attribute command to configure a datasource attribute:

       /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)

    3. Reload the server to confirm the changes:

       :reload

  • Management Console

    1. Section 3.4.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain mode only, select a profile from the drop-down box in the top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources from expanded menu.

    3. Edit the datasource

       1. Select a datasource from the Available Datasources list. The datasource attributes are displayed below.
       2. Click Edit to edit the datasource attributes.
       3. Click Save to finish.

Procedure 6.6. Remove a Non-XA Datasource

• • Management CLI

    1. Section 3.5.2, “Launch the Management CLI”.
    2. Run the following command to remove a non-XA datasource:

       data-source remove --name=DATASOURCE_NAME

  • Management Console

    1. Section 3.4.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain mode only, select a profile from the drop-down box in the top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources.
    3. Select the datasource to be deleted, then click Remove.

Procedure 6.7. Create an XA Datasource, Using Either the Management CLI or the Management Console

• • Management CLI

    1. Section 3.5.2, “Launch the Management CLI”.
    2. Run the following command to create an XA datasource, configuring the variables as appropriate:

       xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS

    3. Configure the XA datasource properties

       1. Set the server name

          Run the following command to configure the server name for the host:

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

       2. Set the database name

          Run the following command to configure the database name:

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

    4. Enable the datasource:

       xa-data-source enable --name=XA_DATASOURCE_NAME

  • Management Console

    1. Section 3.4.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain mode only, select a profile from the drop-down box at the top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources.
    3. Select the XA Datasource tab.

    4. Create a new XA datasource

       1. Click Add.
       2. Enter the new XA datasource attributes in the Create XA Datasource wizard and click Next.
       3. Enter the JDBC driver details in the Create XA Datasource wizard and click Next.
       4. Enter the XA properties and click Next.
       5. Enter the connection settings in the Create XA Datasource wizard.
       6. Click the Test Connection button to test the connection to the XA datasource and verify the settings are correct.
       7. Click Done to finish

Procedure 6.8. Modify an XA Datasource, Using Either the Management CLI or the Management Console

• • Management CLI

    1. Section 3.5.2, “Launch the Management CLI”.

    2. Configure XA datasource attributes

       Use the write-attribute command to configure a datasource attribute:

       /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)

    3. Configure XA datasource properties

       Run the following command to configure an XA datasource subresource:

       /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)

    4. Reload the server to confirm the changes:

       :reload

  • Management Console

    1. Section 3.4.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain Mode only, select a profile from the drop-down box at top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources.
    3. Select the XA Datasource tab.

    4. Edit the datasource

       1. Select the relevant XA datasource from the Available XA Datasources list. The XA datasource attributes are displayed in the Attributes panel below it.
       2. Select the Edit button to edit the datasource attributes.
       3. Edit the XA datasource attributes and select the Save button when done.

Procedure 6.9. Remove an XA Datasource Using Either the Management CLI or the Management Console

• • Management CLI

    1. Section 3.5.2, “Launch the Management CLI”.
    2. Run the following command to remove an XA datasource:

       xa-data-source remove --name=XA_DATASOURCE_NAME

  • Management Console

    1. Section 3.4.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. Select the Configuration tab from the top of the console.
       2. For Domain mode only, select a profile from the drop-down box in the top left.
       3. Expand the Subsystems menu on the left of the console, then expand the Connector menu.
       4. Select Datasources.
    3. Select the XA Datasource tab.
    4. Select the registered XA datasource to be deleted, and click Remove to permanently delete the XA datasource.

Procedure 6.10. Configure Database Connection Validation Settings

1. Choose a Validation Method

   Select one of the following validation methods.

   • <validate-on-match>true</validate-on-match>

     When the <validate-on-match> option is set to true, the database connection is validated every time it is checked out from the connection pool using the validation mechanism specified in the next step.
     If a connection is not valid, a warning is written to the log and it retrieves the next connection in the pool. This process continues until a valid connection is found. If you prefer not to cycle through every connection in the pool, you can use the <use-fast-fail> option. If a valid connection is not found in the pool, a new connection is created. If the connection creation fails, an exception is returned to the requesting application.
     This setting results in the quickest recovery but creates the highest load on the database. However, this is the safest selection if the minimal performance hit is not a concern.

   • <background-validation>true</background-validation>

     When the <background-validation> option is set to true, it is used in combination with the <background-validation-millis> value to determine how often background validation runs. The default value for the <background-validation-millis> parameter is 0 milliseconds, meaning it is disabled by default. This value should not be set to the same value as your <idle-timeout-minutes> setting.
     It is a balancing act to determine the optimum <background-validation-millis> value for a particular system. The lower the value, the more frequently the pool is validated and the sooner invalid connections are removed from the pool. However, lower values take more database resources. Higher values result in less frequent connection validation checks and use less database resources, but dead connections are undetected for longer periods of time.

   Note

   If the <validate-on-match> option is set to true, the <background-validation> option should be set to false. The reverse is also true. If the <background-validation> option is set to true, the <validate-on-match> option should be set to false.

2. Choose a Validation Mechanism

   Select one of the following validation mechanisms.

   • Specify a <valid-connection-checker> Class Name

     This is the preferred mechanism as it optimized for the particular RDBMS in use. JBoss EAP 6 provides the following connection checkers:

     • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
     • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker

   • Specify SQL for <check-valid-connection-sql>

     You provide the SQL statement used to validate the connection.
     The following is an example of how you might specify a SQL statement to validate a connection for Oracle:

     <check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>

     For MySQL or PostgreSQL, you might specify the following SQL statement:

     <check-valid-connection-sql>select 1</check-valid-connection-sql>

3. Set the <exception-sorter> Class Name

   When an exception is marked as fatal, the connection is closed immediately, even if the connection is participating in a transaction. Use the exception sorter class option to properly detect and clean up after fatal connection exceptions. JBoss EAP 6 provides the following exception sorters:

   • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
   • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter

Procedure 6.11. 

• /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
  

  /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
  

• /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
  

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