1. Managed Domain

   For a Managed Domain, provide the file name of the configuration file as an option to the --domain-config parameter. You do not need to give the full path, if the configuration file resides in the EAP_HOME/domain/configuration/ 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

   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

2. Standalone server

   For a Standalone Server, provide the filename of the configuration file as an option to the --server-config parameter. You do not need to give the full path to the configuration file if it is in the EAP_HOME/standalone/configuration/ directory.

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

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

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

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

Procedure 2.1. Task:

1. Stop an instance which was started interactively from a command prompt.

   Press Ctrl-C in the terminal where JBoss Enterprise Application Platform 6 is running.

2. Stop an instance which was started as an operating system service.

   Depending on your operating system, use one of the following procedures.

   • Red Hat Enterprise Linux

     For Red Hat Enterprise Linux, if you have written a service script, use its stop facility. This needs to be written into the script. Then you can use service scriptname stop, where scriptname is the name of your script.

   • Microsoft Windows Server

     In Microsoft Windows, use the net service command, or stop the service from the Services applet in the Control Panel.

3. Stop an instance which is running in the background (Red Hat Enterprise Linux)

   1. Locate the instance from the process list. One option is to run the command ps aux |grep "[j]ava -server". This returns one result for each JBoss Enterprise Application Platform 6 instance that is running on the local machine.
   2. Send the process the TERM signal, by running kill process_ID, where process_ID is the number in the second field of the ps aux command above.

Procedure 2.2. Task

1. Copy the start-up script to the /etc/init.d/ directory

   The start-up script and an associated configuration file are located in the EAP_HOME/bin/init.d/ directory. Copy each of these files to the /etc/init.d/ directory.

   [user@host init.d]$ sudo cp jboss-as-standalone.sh jboss-as.conf /etc/init.d

2. Add the start-up script as a service.

   Add the new jboss-as-standalone.sh service to list of automatically started services, using the chkconfig service management command.

   [user@host init.d]$ sudo chkconfig --add jboss-as-standalone.sh

3. Edit the script options.

   If desired, edit the jboss-as.conf file to customize start-up options for JBoss Enterprise Application Platform and the JVM. Use the comments in the file as guidance. It is recommended to set the JBOSS_HOME variable in this file, to point to the directory where you extracted JBoss Enterprise Application Platform 6. Do not add a trailing slash (/) at the end of the directory name.

4. Edit the script itself.

   You may need to edit the start-up script itself. It makes certain assumptions about the name of your start-up file and the location of your JBoss Enterprise Application Platform instance. Customize the script, paying special attention to the following variables, which you will need to customize to start JBoss Enterprise Application Platform 6 as a managed domain.
   • JBOSS_HOME - the location where JBoss Enterprise Application Platform 6 is extracted
   • JBOSS_USER - the user with the ability to run JBoss Enterprise Application Platform. This should be a non-privileged user, as no superuser privileges as required.
   • JBOSS_CONFIG - the name of the configuration file used to start JBoss Enterprise Application Platform 6, such as domain.xml or standalone.xml
   • JBOSS_SCRIPT - the script used to start JBoss Enterprise Application Platform 6, such as domain.sh or standalone.sh

5. Start the service.

   If desired, start the new service using the standard syntax for starting Red Hat Enterprise Linux services.

   [user@host bin]$ sudo service jboss-as-standalone.sh start

Procedure 2.3. Task

1. Download the Native Utilities package for your architecture.

   32-bit, 64-bit, and Itanium 64-bit packages are available from the Red Hat Customer Portal at https://access.redhat.com. For more information on downloading software from the Red Hat Customer Portal, refer to the JBoss Enterprise Application Platform 6 Installation Guide, available here: https://access.redhat.com/knowledge/docs/JBoss_Enterprise_Application_Platform/.

2. Unzip the downloaded archive.

   Unzip the archive into a new folder.
   Result: The modules\native\bin\ folder is created.

   The modules\native\bin\ folder contains the files you need to install JBoss Enterprise Application Platform 6 as a service. These services are part of Procrun, which is a series of wrapper scripts provided by Apache Commons. To learn more about Procrun and its syntax, refer to the following link: http://commons.apache.org/daemon/procrun.html.

3. Run the modules\sbin\prunsrv.exe executable.

   prunsrv.exe install path_to_startup_script

   Result

   The service is installed. JBoss Enterprise Application Platform 6 is listed in the Services applet services.msc.

4. Manage your service.

   Use the modules\bin\prunmgr.exe executable to manage, edit, add, or delete services. The following command-line options are supported:
   • run
   • service
   • start
   • stop
   • update
   • install
   • delete
   • pause [seconds]
   • version
   • help
   The general syntax is:

   prunmgr.exe command service_name

Procedure 2.4. Task

1. Navigate to Server Instances in the Management Console

   1. Select the Runtime tab from the top-right of the console.
   2. Select Domain Status → Server Instances from the menu on the left of the console.
   

   Figure 2.1. Server Instances

2. Select a server

   From the list of Server Instances, select the server you want to start. Servers that are running are indicated by a check mark.

3. Click the Start button

   Click on the Start button above the server list to open the confirmation dialogue box. Click the Confirm button to start the server.
   

   Figure 2.2. Confirm server modification

Procedure 2.5. Task

1. Navigate to Server Instances in the Management Console

   1. Select the Runtime tab from the top-right of the console.
   2. Select Domain Status → Server Instances from the menu on the left of the console.
   

   Figure 2.4. Server Instances

2. Select a server

   From the list of Server Instances, select the server you want to stop. Servers that are running are indicated by a check mark.

3. Click the Stop button

   Click on the Stop button above the server list to open the confirmation dialogue box. Click the Confirm button to start the server.
   

   Figure 2.5. Confirm server modification

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/configuration/standalone_xml_history/current/standalone.v1.xml 

2. Start the server with this instance 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 

• Save a snapshot

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

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

Procedure 2.6. Task

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 snapshot instance by passing in the filename.

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

Procedure 2.7. 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.8. 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.9. Task

• 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"
          ]
      }
  }
  

Procedure 3.1. Task

1. Navigate to the Management Console start page

   Navigate to the Management Console in your web browser. The default location is http://localhost:9990/console/, where port 9990 is predefined as the Management Console socket binding.

2. Log in to the Management Console

   Enter the username and password of the account that you created previously to log into the Management Console login screen.
   

   Figure 3.1. Log in screen for the Management Console

Procedure 3.2. Task

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.3. Task

1. Navigate to the server's Server Configuration panel in the Management Console

   1. Select the Server tab from the top-right of the console.
   2. Expand the Server Configurations menu item on the left of the console and select the relevant server from the list.
   

   Figure 3.2. Server configuration

2. Edit the server configuration

   1. Select the Edit button beneath the server list.
   2. Make changes to the configuration attributes.
   3. Select the Save button beneath the server list.

Procedure 3.4. Task

1. Navigate to the Manage Deployments panel in the Management Console

   1. Select the Runtime tab from the top right of the console.
   2. For either a managed domain or a standalone server, select the Deployments → Manage Deployments option from the menu on the left of the console.
   The Manage Deployments panel appears.
   

   Figure 3.3. Manage domain deployments

2. Add deployment content

   Select the Add Content button in the top right of the Deployments panel. An Upload dialog box appears.

3. Choose a file to deploy

   In the dialog box, select the Choose File button. Browse to the file you want to deploy and select it for upload. Select the Next button to proceed once a file has been selected.
   

   Figure 3.4. Deployment selection

4. Verify deployment names

   Verify the deployment name and runtime name that appear in the Upload dialog box. Select the Save button to upload the file once the names are verified.
   

   Figure 3.5. Verify deployment names

Procedure 3.5. Task

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

   Select the Server tab from the top-right of the console.

2. Create a new configuration

   1. Select the Add button at the top of the Server Configuration panel.
   2. Edit the basic server settings in the Create Server Configuration dialog.
   3. Select the Save button to save the new server configuration.

Procedure 3.6. Task

1. Navigate to the Logging panel in the Management Console

   1. If you are working with a managed domain, select the Profiles tab from the top-right 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, select the Core → Logging option from the menu on the left of the console.
   3. Click on the Log Categories tab in the top of the console.
   

   Figure 3.8. Logging panel

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 select the Edit button in the Details section below.
   2. Set the log level for the category with the Log Level drop-down box. Select the Save button when done.

Procedure 3.7. Task

1. Navigate to the Server Groups view

   Select the Profiles tab in the top-right corner.
2. Select the Group Configurations tab under the Server Groups menu in the left hand column.
   

   Figure 3.9. The Server Groups view

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 you want to add the server group to.
   3. Select the socket binding you want to add the server group to.
   4. Select the Save button to save your new group.
   

   Figure 3.10. The Create Server Group dialog

Procedure 3.8. Task

• • 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 Windows

    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.9. Task

• Run the quit command

  From the Management CLI, enter the quit command:

  [domain@localhost:9999 /] quit
  Closed connection to localhost:9999

Procedure 3.10. Task

• 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

Procedure 3.11. Task

1. Run the help command

   From the Management CLI, enter the help command:

   [standalone@localhost:9999 /] help

2. Get 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, execute the help command with '--help' as the argument.

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

Procedure 3.12. Task

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.3.7, “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.

Procedure 3.13. Task

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.1. 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.2. 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-children-types command on a resource node, passing the operation name as a parameter. Refer to Example 3.3, “Determine operation parameters” for details.

      Example 3.3. 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" => false
          }
      }

2. Enter the full operation request

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

   Example 3.4. Example operation request

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

Procedure 3.14. Task

• 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.3.7, “Use Operations and Commands in the Management CLI”.

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

Procedure 3.15. Task

• 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.6. Use the whoami in a standalone instance

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

Procedure 3.16. Task

• Run the version command

  From the Management CLI, enter the version command:

  [domain@localhost:9999 /] version

Procedure 3.17. Task

• 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.3.7, “Use Operations and Commands in the Management CLI”.

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

Procedure 3.18. Task

• 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.3.7, “Use Operations and Commands in the Management CLI”.

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

Procedure 3.19. Task

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.9. Using the read-resource operation at the root level

   [standalone@localhost:9999 /]:read-resource
   {
       "outcome" => "success",
       "result" => {
           "deployment" => undefined,
           "management-major-version" => 1,
           "management-minor-version" => 2,
           "name" => "hostname",
           "namespaces" => [],
           "product-name" => "EAP",
           "product-version" => "6.0.0.GA",
           "profile-name" => undefined,
           "release-codename" => "Steropes",
           "release-version" => "7.1.2.Final-redhat-1",
           "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.configadmin" => 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.logging" => undefined,
               "org.jboss.as.mail" => undefined,
               "org.jboss.as.naming" => undefined,
               "org.jboss.as.osgi" => 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,
               "configadmin" => undefined,
               "datasources" => undefined,
               "deployment-scanner" => undefined,
               "ee" => undefined,
               "ejb3" => undefined,
               "infinispan" => undefined,
               "jaxrs" => undefined,
               "jca" => undefined,
               "jdr" => undefined,
               "jmx" => undefined,
               "jpa" => undefined,
               "mail" => undefined,
               "naming" => undefined,
               "osgi" => 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.10. Expose child node resources from the root node

   [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
   {
       "outcome" => "success",
       "result" => {
           "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" => 8433,
           "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.11. 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" => {
           "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" => 8433,
           "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 byes received by the http connector.

   Example 3.12. 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" => {
           "bytesReceived" => "0",
           "bytesSent" => "0",
           "enable-lookups" => false,
           "enabled" => true,
           "errorCount" => "0",
           "executor" => undefined,
           "max-connections" => undefined,
           "max-post-size" => 2097152,
           "max-save-post-size" => 4096,
           "maxTime" => "0",
           "name" => "http",
           "processingTime" => "0",
           "protocol" => "HTTP/1.1",
           "proxy-name" => undefined,
           "proxy-port" => undefined,
           "redirect-port" => 8433,
           "requestCount" => "0",
           "scheme" => "http",
           "secure" => false,
           "socket-binding" => "http",
           "ssl" => undefined,
           "virtual-server" => undefined
       }
   }
   

Procedure 3.20. Task

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.3.7, “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.21. Task

• Run the reload operation

  From the Management CLI, use the reload 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.3.7, “Use Operations and Commands in the Management CLI”.

  [standalone@localhost:9999 /]:reload
  {"outcome" => "success"}
  

Procedure 3.22. Task

• 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.3.7, “Use Operations and Commands in the Management CLI”.

  [standalone@localhost:9999 /]:shutdown

Procedure 3.23. Task

• 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.24. Task

• Run the history command

  From the Management CLI, enter the history command:

  [standalone@localhost:9999 /] history

Procedure 3.25. Task

• Run the history --clear command

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

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

Procedure 3.26. Task

• Run the history --disable command

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

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

Procedure 3.27. Task

• Run the history --enable command

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

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

Procedure 4.1. Task

1. Invoke 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.

   Select 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. Choose the realm for the user.

   The next prompt refers to the realm where the user will be added. For a user with permissions to manage JBoss Enterprise Application Platform 6, choose the default, which is ManagementRealm.

4. Enter the desired username and password.

   When prompted, enter the security realm, username and password. Pressing ENTER selects the default realm of ManagementRealm, which allows the user to administer JBoss Enterprise Application Platform 6 using the management interfaces. You must add at least one user to this realm. You are prompted to confirm the information. If you are satisfied, type yes .

5. Choose whether the user represents a remote JBoss Enterprise Application Platform 6 server instance.

   Besides administrators, the other type of user which occasionally needs to be added to JBoss Enterprise Application Platform 6 in the ManagementRealm is a user representing another instance of JBoss Enterprise Application Platform 6, which needs to 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.

6. 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.

7. 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

• Configure Interface Attributes

  Choose either the Management CLI or the Management Console to configure your interface attributes as required.

  • 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

       Use the add operation to create a new interface if required. You can run this command from the root of the Management CLI session, which in the following example 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

       Use the write 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 inet-address value to 12.0.0.8

       /interface=interfacename/:write(inet-address=12.0.0.8)

    3. Edit Interface 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.

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

  • Configure Interface Attributes with the Management Console

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

    1. Log into the Management Console.

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

    2. If you use a Managed Domain, choose the correct profile.

       Select the Profiles tab at the top right, and then select the correct profile from the Profile menu at the top left of the next screen.

    3. Select the Interfaces item from the navigation menu.

       Select the Interfaces menu item from the navigation menu.

    4. Add a New Interface

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

    5. Edit Interface Attributes

       1. Select the Interface to edit and click the Edit button.
       2. Enter any required values for Name, Inet Address and Address Wildcard.
       3. Click the Save to finish.

• 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 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 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. Select the Profile tab

       Select the Profiles tab at the top right.

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

       Select the Socket Binding menu item from the navigation menu. If you are using a Managed Domain, select the desired group in the Socket Binding Groups menu.

    4. Add a New Socket Binding

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

    5. Edit Interface Attributes

       1. Select the Socket Binding to edit and click the Edit button.
       2. Enter any required values such as Name, Interface or Port.
       3. Click the 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 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.

       [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 Server tab

       Select the Server tab at the top right.

    3. Edit Port Offset Attributes

       1. Select the server under the Configuration Name section and click the Edit button.
       2. Enter any desired values in the Port Offset field.
       3. Click the Save button to finish.

Procedure 5.1. Task

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. Task

1. Select the Profile tab, in the top right corner of the console.
2. Select the Interfaces option under General Configuration.
3. Select the named network interface to configure.
4. Click the Edit button.
5. Set the inet address to:

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

6. Click the Save button to save the changes.
7. Restart the server to implement the changes.

Procedure 5.3. Task

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. Task

1. Access the Management Console.

   Section 3.2.2, “Log in to the Management Console”

2. Deploy the JAR file to your server or server group.

   If you use a managed domain, deploy the JAR file to a server group. Otherwise, deploy it to your server. See Section 8.2.2, “Deploy an Application Using the Management Console”.

Procedure 6.2. Task

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 below:

   Example 6.1. Example module.xml file

   <?xml version="1.0" encoding="UTF-8"?>
   <module xmlns="urn:jboss:module:1.0" name="com.mysql">
     <resources>
       <resource-root path="mysql-connector-java-5.1.15.jar"/>
     </resources>
     <dependencies>
       <module name="javax.api"/>
       <module name="javax.transaction.api"/>
     </dependencies>
   </module>
   

   The module name, com.mysql, should match the directory structure for the module.
4. Start the Server.
5. Start the Management CLI.
6. Run the following CLI command to add the JDBC driver module as a driver:

   /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.2. Example CLI Command

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

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.3. 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.4. Example jboss-deployment-structure.xml file

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

Procedure 6.4. Task

• • 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. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.1. Datasources panel

    3. Create a new datasource

       1. Select the Add button 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 proceed with the Next button.
       4. Enter the connection settings in the Create Datasource wizard and select the Done button.

Procedure 6.5. Task

• • Management CLI

    1. Section 3.3.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.2.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.2. Datasources panel

    3. Edit the datasource

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

Procedure 6.6. Task

• • Management CLI

    1. Section 3.3.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.2.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.3. Datasources panel

    3. Select the registered datasource to be deleted, and click the Remove button in the top right corner of the console.

Procedure 6.7. Task

• • Management CLI

    1. Section 3.3.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.2.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.4. Datasources panel

    3. Select the XA Datasource panel.

    4. Create a new XA datasource

       1. Select the Add button at the top of the XA Datasources panel.
       2. Enter the new XA datasource attributes in the Create XA Datasource wizard and proceed with the Next button.
       3. Enter the JDBC driver details in the Create XA Datasource wizard and proceed with the Next button.
       4. Edit the XA properties and proceed with the Next button.
       5. Enter the connection settings in the Create XA Datasource wizard and select the Done button.

Procedure 6.8. Task

• • Management CLI

    1. Section 3.3.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.2.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.5. Datasources panel

    3. Select the XA Datasource panel.

    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. Task

• • Management CLI

    1. Section 3.3.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.2.2, “Log in to the Management Console”.

    2. Navigate to the Datasources panel in the Management Console

       1. • Standalone Mode

            Select the Profile tab from the top-right of the console.

          • Domain Mode

            1. Select the Profiles tab from the top-right of the console.
            2. Select the appropriate profile from the drop-down box in the top left.
            3. Expand the Subsystems menu on the left of the console.
       2. Select Connector → Datasources from the menu on the left of the console.
       

       Figure 6.6. Datasources panel

    3. Select the XA Datasource panel.
    4. Select the registered XA datasource to be deleted, and click the Remove button in the top right corner of the console.

Procedure 8.1. Task

1. Navigate to the Manage Deployments panel in the Management Console

   1. Select the Runtime tab from the top right of the console.
   2. Select the Deployments → Manage Deployments option from the menu on the left of the console.

2. Deploy an application

   The deployment method will differ depending on whether you are deploying to a standalone server instance or a managed domain.

   • Deploy to a standalone server instance

     The Deployments table shows all available application deployments and their status.
     

     Figure 8.1. Available deployments

     1. Enable the application in a standalone server instance

        Click on the Enable button in the Deployments table to enable the application deployment.

     2. Confirm

        Click on the confirm button to confirm that the application will be enabled on the server instance.
        

        Figure 8.2. Available deployments in a standalone server

   • Deploy to a managed domain

     The Deployment Content section contains a Content Repository table showing all available application deployments and their status.
     

     Figure 8.3. Available deployments in a managed domain

     1. Enable the application in a Managed Domain

        Click on the Add to Groups button in the Content Repository table.

     2. Select server groups

        Check the boxes for each of the server groups that you want the application to be added to and click on the Save button to continue.
        

        Figure 8.4. Select server groups for application deployment

     3. Confirm

        Click on the Server Group Deployments tab to view the Server Groups table. Your application is now deployed to the server groups that you have selected.
        

        Figure 8.5. Confirmation of application deployment to server groups