Management CLI Guide

You can launch the management CLI by running the jboss-cli script provided with JBoss EAP.

$ EAP_HOME/bin/jboss-cli.sh

See Connect to the Server for details on launching the management CLI and connecting to the server in one step using the --connect argument.

For a complete listing of all available jboss-cli script arguments and their purposes, use the --help argument or see the Management CLI Startup Arguments section.

You can connect to a running standalone server or managed domain by using the connect command.

connect

The default host and port configuration is localhost:9990. If the server is listening on a different host and port, then these need to be provided to the connect command.

connect 192.168.0.1:9991

You can also launch the management CLI and connect to the server in one step using the --connect argument (and the --controller argument if necessary).

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

In JBoss EAP 7.2, to connect using the http-remoting protocol, use:

connect http-remoting://192.168.0.1:9990

The management CLI provides several ways for you to get help with using the management CLI.

See the Management CLI Commands section for a listing of management CLI commands.

You can quit the management CLI by entering the quit command.

quit

You can issue management CLI commands without launching and interacting with the management CLI. This is useful for processing batches of commands and executing commands from scripts. You can either pass in the commands or pass in a file that contains commands to the jboss-cli startup script.

Pass in Commands

You can use the --command argument to provide a single CLI command to execute. The management CLI will terminate once the commands have completed.

$ EAP_HOME/bin/jboss-cli.sh --connect --command="/interface=public:read-attribute(name=inet-address,resolve-expressions=true)"

The output from each command provided is displayed as it executes.

{
    "outcome" => "success",
    "result" => "127.0.0.1"
}

You can also use the --commands argument to provide a comma-separated list of CLI commands to execute.

Pass in a File of Commands

You can use the --file argument to pass in a text file of CLI commands to execute, with each command on a separate line in the file.

$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/cli_commands.txt

The output from each command in the file is displayed as it executes.

{
    "outcome" => "success",
    "result" => "NORMAL"
}
helloworld.war

You can use the --echo-command argument to include the prompt and command with the output. This can be useful when resolving failures by matching the output to the command that was executed.

$ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/cli_commands.txt --echo-command

The command and its output are displayed as it executes.

[standalone@localhost:9990 /] :read-attribute(name=running-mode)
{
    "outcome" => "success",
    "result" => "NORMAL"
}
[standalone@localhost:9990 /] ls /deployment
helloworld.war

You can change to a different node path by using the cd command and providing the desired path. When the management CLI is first launched, it is at the root level (/).

cd /subsystem=datasources
cd data-source=ExampleDS

You can print the path of the current node by using the pwd command. When the management CLI is first launched, the path is at the root level (/).

cd /subsystem=undertow
cd server=default-server
pwd

The above example changes the path using the cd command and then outputs the following to the console:

/subsystem=undertow/server=default-server

You can list the contents of a particular node path by using the ls command. If the path ends on a node name, that resource’s attributes will be listed as well.

The below example navigates the standard-sockets socket binding group and then lists its contents.

cd /socket-binding-group=standard-sockets
ls -l

ATTRIBUTE         VALUE                                 TYPE
default-interface public                                STRING
name              standard-sockets                      STRING
port-offset       ${jboss.socket.binding.port-offset:0} INT

CHILD                                      MIN-OCCURS MAX-OCCURS
local-destination-outbound-socket-binding  n/a        n/a
remote-destination-outbound-socket-binding n/a        n/a
socket-binding                             n/a        n/a

The same result can be achieved from anywhere in the resource tree hierarchy by specifying the node path to the ls command.

ls -l /socket-binding-group=standard-sockets

ATTRIBUTE         VALUE                                 TYPE
default-interface public                                STRING
name              standard-sockets                      STRING
port-offset       ${jboss.socket.binding.port-offset:0} INT

CHILD                                      MIN-OCCURS MAX-OCCURS
local-destination-outbound-socket-binding  n/a        n/a
remote-destination-outbound-socket-binding n/a        n/a
socket-binding                             n/a        n/a

You can also use the --resolve-expressions parameter to resolve the expressions of the returned attributes to their value on the server.

ls -l /socket-binding-group=standard-sockets --resolve-expressions

ATTRIBUTE         VALUE            TYPE
default-interface public           STRING
name              standard-sockets STRING
port-offset       0                INT

CHILD                                      MIN-OCCURS MAX-OCCURS
local-destination-outbound-socket-binding  n/a        n/a
remote-destination-outbound-socket-binding n/a        n/a
socket-binding                             n/a        n/a

In this example, the port-offset attribute shows its resolved value (0) instead of the expression (${jboss.socket.binding.port-offset:0}).

When you run the management CLI in interactive mode and the operation results in multiple pages of output, the command processor pauses the screen at the end of the first page. This allows you to page through the output one line or page at a time. The occurrence of multiple pages of output is indicated by a line of text displaying --More(NNN%)-- at the end of the output.

The following is an example of a management CLI command that provides more than one page of output.

/subsystem=undertow:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
      "default-security-domain" => "other",
      "default-server" => "default-server",
      "default-servlet-container" => "default",
      "default-virtual-host" => "default-host",
      "instance-id" => expression "${jboss.node.name}",
      "statistics-enabled" => false,
  Pre    "application-security-domain" => {"other" => {
          "enable-jacc" => false,
          "http-authentication-factory" => "application-http-authentication",
          "override-deployment-config" => false,
          "setting" => undefined
      }},
      "buffer-cache" => {"default" => {
          "buffer-size" => 1024,
          "buffers-per-region" => 1024,
--More(7%)--

Navigating Multi-page Output

When you encounter the line of text indicating that there is more output, you can proceed using one of the following options.

Searching Multi-page Output

You can search for text within multi-page output.

You can also use the up and down arrows to browse through the search history.

When running the management CLI in interactive mode, you can use keyboard shortcuts to quickly edit a management CLI command.

The keyboard shortcuts you can use vary depending on which supported platform you are running:

You can use the read-resource operation to view a resource’s attribute values.

:read-resource

You can specify parameters to provide complete information about child resources, recursively. You can also specify parameters to include runtime attributes, resolve expressions, and include aliases. Use read-operation-description(name=read-resource) to see the description of all available parameters for read-resource.

The following example reads the attributes for a deployment. It includes details such as the deployment name, whether it is enabled, and the last time it was enabled.

/deployment=DEPLOYMENT_NAME:read-resource
{
    "outcome" => "success",
    "result" => {
        ...
        "enabled" => true,
        "enabled-time" => 1453929902598L,
        "enabled-timestamp" => "2016-01-27 16:25:02,598 EST",
        "name" => "DEPLOYMENT_NAME",
        "owner" => undefined,
        "persistent" => true,
        "runtime-name" => "DEPLOYMENT_NAME",
        "subdeployment" => undefined,
        "subsystem" => {
            "undertow" => undefined,
            "logging" => undefined
        }
    }
}

Include Runtime Attributes

The include-runtime parameter can be used to retrieve runtime attributes.

The following example reads the attributes for a deployment. In addition to persistent attributes, it also includes runtime attributes, such as the deployment status and the last time it was disabled.

/deployment=DEPLOYMENT_NAME:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        ...
        "disabled-time" => undefined,
        "disabled-timestamp" => undefined,
        "enabled" => true,
        "enabled-time" => 1453929902598L,
        "enabled-timestamp" => "2016-01-27 16:25:02,598 EST",
        "name" => "DEPLOYMENT_NAME",
        "owner" => undefined,
        "persistent" => true,
        "runtime-name" => "DEPLOYMENT_NAME",
        "status" => "OK",
        "subdeployment" => undefined,
        "subsystem" => {
            "undertow" => undefined,
            "logging" => undefined
        }
    }
}

You can also use the not operator (!) when passing in boolean parameters. For example:

Read Child Resources Recursively

The recursive parameter can be used to retrieve attributes recursively from child resources.

The following example reads the attributes for a deployment. In addition to the resource’s own attributes, it recursively returns the attributes for its child resources, such as the undertow subsystem configuration.

/deployment=DEPLOYMENT_NAME:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        ...
        "enabled" => true,
        "enabled-time" => 1453929902598L,
        "enabled-timestamp" => "2016-01-27 16:25:02,598 EST",
        "name" => "DEPLOYMENT_NAME",
        "owner" => undefined,
        "persistent" => true,
        "runtime-name" => "DEPLOYMENT_NAME",
        "subdeployment" => undefined,
        "subsystem" => {
            "undertow" => {
                "context-root" => "/test",
                "server" => "default-server",
                "virtual-host" => "default-host",
                "servlet" => undefined,
                "websocket" => undefined
            },
            "logging" => {"configuration" => undefined}
        }
    }
}

Exclude Default Values

The include-defaults parameter can be used to show or hide default values when reading attributes for a resource. This is true by default, meaning that default values will be shown when using the read-resource operation.

The following example uses the read-resource operation on the undertow subsystem.

/subsystem=undertow:read-resource
{
    "outcome" => "success",
    "result" => {
        "default-security-domain" => "other",
        "default-server" => "default-server",
        "default-servlet-container" => "default",
        "default-virtual-host" => "default-host",
        "instance-id" => expression "${jboss.node.name}",
        "statistics-enabled" => false,
        "buffer-cache" => {"default" => undefined},
        "configuration" => {
            "filter" => undefined,
            "handler" => undefined
        },
        "server" => {"default-server" => undefined},
        "servlet-container" => {"default" => undefined}
    }
}

The following example also uses the read-resource operation on the undertow subsystem, but sets the include-defaults parameter to false. Several attributes, such as statistics-enabled and default-server, now display undefined as their value instead of the default value.

/subsystem=undertow:read-resource(include-defaults=false)
{
    "outcome" => "success",
    "result" => {
        "default-security-domain" => undefined,
        "default-server" => undefined,
        "default-servlet-container" => undefined,
        "default-virtual-host" => undefined,
        "instance-id" => undefined,
        "statistics-enabled" => undefined,
        "buffer-cache" => {"default" => undefined},
        "configuration" => {
            "filter" => undefined,
            "handler" => undefined
        },
        "server" => {"default-server" => undefined},
        "servlet-container" => {"default" => undefined}
    }
}

Resolve Expressions

The resolve-expressions parameter can be used to resolve the expressions of the returned attributes to their value on the server.

Attributes with expressions as their values use the format ${PARAMETER:DEFAULT_VALUE}. See Property Replacement in the Configuration Guide for more information.

The following example reads the attributes for a deployment. The instance-id attribute shows its resolved value (test-name) instead of the expression (${jboss.node.name}).

/subsystem=undertow:read-resource(resolve-expressions=true)
{
    "outcome" => "success",
    "result" => {
        "default-security-domain" => "other",
        "default-server" => "default-server",
        "default-servlet-container" => "default",
        "default-virtual-host" => "default-host",
        "instance-id" => "test-name",
        "statistics-enabled" => false,
        "buffer-cache" => {"default" => undefined},
        "configuration" => {
            "filter" => undefined,
            "handler" => undefined
        },
        "server" => {"default-server" => undefined},
        "servlet-container" => {"default" => undefined}
    }
}

You can use the read-resource-description operation to a description about a resource and its attributes.

:read-resource-description

You can specify parameters to provide complete descriptions about child resources, recursively. You can also specify parameters to include details of the resource’s operations and notifications. Use read-operation-description(name=read-resource-description) to see the description of all available parameters for read-resource-description.

The following example displays the attribute details for a buffer cache.

/subsystem=undertow/buffer-cache=default:read-resource-description
{
    "outcome" => "success",
    "result" => {
        "description" => "The buffer cache used to cache static content",
        "attributes" => {
            "buffer-size" => {
                "type" => INT,
                "description" => "The size of an individual buffer",
                "expressions-allowed" => true,
                "nillable" => true,
                "default" => 1024,
                "min" => 0L,
                "max" => 2147483647L,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "resource-services"
            },
            "buffers-per-region" => {
                "type" => INT,
                "description" => "The numbers of buffers in a region",
                "expressions-allowed" => true,
                "nillable" => true,
                "default" => 1024,
                "min" => 0L,
                "max" => 2147483647L,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "resource-services"
            },
            "max-regions" => {
                "type" => INT,
                "description" => "The maximum number of regions",
                "expressions-allowed" => true,
                "nillable" => true,
                "default" => 10,
                "min" => 0L,
                "max" => 2147483647L,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "resource-services"
            }
        },
        "operations" => undefined,
        "notifications" => undefined,
        "children" => {}
    }
}

See Resource Attribute Details to learn more about the fields returned for attributes.

You can use the read-attribute operation to view the current value of a single attribute.

:read-attribute(name=ATTRIBUTE_NAME)

The following example displays the log level for the root logger by reading the level attribute.

/subsystem=logging/root-logger=ROOT:read-attribute(name=level)
{
    "outcome" => "success",
    "result" => "INFO"
}

One advantage of using the read-attribute operation is the ability to expose the current runtime value of an attribute.

/interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}

The resolved-address attribute is a runtime attribute. This attribute is not displayed when using the read-resource operation on the public interface unless you pass in the include-runtime parameter. And even then, it is displayed with the rest of the resource’s other attributes.

You can also use the include-defaults and resolve-expressions parameters. See Display Resource Values for details on these parameters.

You can use the write-attribute operation to update the value of an attribute for a resource.

:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)

The following example disables the deployment scanner by setting the scan-enabled attribute to false.

/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}

The response from the operation request shows that it was successful. You can also confirm the result by using the read-attribute operation to read the scan-enabled attribute, which now shows as false.

/subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}

You can set the value of an attribute to undefined. If this attribute has a default value, that will be used.

The following example undefines the level attribute for the root logger.

/subsystem=logging/root-logger=ROOT:undefine-attribute(name=level)

The default value for the level attribute is ALL. You can see that this default is used when performing the read-resource operation.

/subsystem=logging/root-logger=ROOT:read-resource
{
    "outcome" => "success",
    "result" => {
        "filter" => undefined,
        "filter-spec" => undefined,
        "handlers" => [
            "CONSOLE",
            "FILE"
        ],
        "level" => "ALL"
    }
}

To view the resource without the default values being read, you must use set the include-defaults parameter to false. You can now see that the value of level is undefined.

/subsystem=logging/root-logger=ROOT:read-resource(include-defaults=false)
{
    "outcome" => "success",
    "result" => {
        "filter" => undefined,
        "filter-spec" => undefined,
        "handlers" => [
            "CONSOLE",
            "FILE"
        ],
        "level" => undefined
    }
}

You can use the read-operation-names list the available operations for a given resource.

:read-operation-names

The following example lists the available operations to perform on a deployment.

/deployment=DEPLOYMENT_NAME:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add",
        "deploy",
        "list-add",
        "list-clear",
        "list-get",
        "list-remove",
        "map-clear",
        "map-get",
        "map-put",
        "map-remove",
        "query",
        "read-attribute",
        "read-attribute-group",
        "read-attribute-group-names",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "redeploy",
        "remove",
        "undefine-attribute",
        "undeploy",
        "whoami",
        "write-attribute"
    ]
}

Use the read-operation-description operation to display an operation description.

You can use the read-operation-description operation to display a description of a certain operation for a resource. This also includes parameter descriptions and which parameters are required.

:read-operation-description(name=OPERATION_NAME)

The following example provides the description and parameter information for the add operation on a system property.

/system-property=SYSTEM_PROPERTY:read-operation-description(name=add)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "add",
        "description" => "Adds a system property or updates an existing one.",
        "request-properties" => {"value" => {
            "type" => STRING,
            "description" => "The value of the system property.",
            "expressions-allowed" => true,
            "required" => false,
            "nillable" => true,
            "min-length" => 0L,
            "max-length" => 2147483647L
        }},
        "reply-properties" => {},
        "read-only" => false,
        "runtime-only" => false
    }
}

Occasionally when creating management CLI requests, you may need to add a value that contains special characters. Certain special characters, such as those used in the syntax of a management CLI request, must be entered in a particular manner.

In many cases, but not all, enclosing the value in double quotes ("") is sufficient. If you are unsure whether your special character was accepted properly, be sure to read the attribute or resource after adding the value to verify that it was saved correctly.

See the sections below for information on how to process the following special characters.

Whitespace

By default, whitespace is trimmed from values added through the management CLI. You can include a space in a value by enclosing the value in double quotes ("") or braces ({}), or by escaping it using a backslash (\).

/system-property=test1:add(value="Hello World")
/system-property=test2:add(value={Hello World})
/system-property=test3:add(value=Hello\ World)

This will set the value to Hello World.

Quotation Marks

You can use a single quotation mark (') in a value by enclosing the value in double quotes ("") or by escaping it using a backslash (\). The following examples set the value of system properties to server's.

/system-property=test1:add(value="server's")
/system-property=test2:add(value=server\'s)

You can use a double quotation mark (") in a value by escaping it using a backslash (\). Depending on the location of the quotation mark in the value, you might also need to enclose the value in double quotes (""). The following example sets the value of a system property to "quote".

/system-property=test1:add(value="\"quote\"")

Commas

You can use a comma (,) in a value by enclosing the value in double quotes ("").

/system-property=test:add(value="Last,First")

This will set the value to Last,First.

Parentheses

You can include parentheses (()) in a value by enclosing the value in double quotes ("") or braces ({}), or by escaping the parenthesis using a backslash (\).

/system-property=test1:add(value="one(1)")
/system-property=test2:add(value={one(1)})
/system-property=test3:add(value=one\(1\))

This will set the value to one(1).

Braces

You can include braces ({}) in a value by enclosing the value in double quotes ("").

/system-property=test:add(value="{braces}")

This will set the value to {braces}.

Brackets

You can include brackets ([]) in a value by enclosing the value in double quotes ("").

/system-property=test:add(value="[brackets]")

This will set the value to [brackets].

Diacritic Marks

Diacritic marks, such as ñ, ř, or ý, can be used when adding a value using the management CLI.

/system-property=test1:add(value=Año)

However, do not enclose the value in double quotes (""). This can cause the diacritic mark to be replaced with a question mark (?). If the value has whitespace that needs to be maintained, instead enclose the value in braces ({}) or escape the space with a backslash (\).

/system-property=test2:add(value={Dos años})
/system-property=test3:add(value=Dos\ años)

This will set the value to Dos años.

You can specify operation headers to control certain aspects of how an operation executes. The following operation headers are available:

deployment deploy-file /path/to/DEPLOYMENT.war --headers={allow-resource-service-restart=true}

/subsystem=infinispan/cache-container=test:remove() {allow-resource-service-restart=true}

Use a semicolon (;) to separate multiple operation headers.

The management CLI supports if-else control flow, which allows you to choose which set of commands and operations to execute based on a condition. The if condition is a boolean expression which evaluates the response of the management command or operation specified after the of keyword.

Expressions can contain any of the following items:

The below example uses the match regular expression (~=) operator to check whether the value of the features system property contains jgroups.

if (result ~= ".*jgroups.*") of /:resolve-expression(expression=${features})
  echo Configuring JGroups
end-if

The below example attempts to read the system property test. If outcome is not success (meaning that the property does not exist), then the system property will be added and set to true.

if (outcome != success) of /system-property=test:read-resource
    /system-property=test:add(value=true)
end-if

The condition above uses outcome, which is returned when the CLI command after the of keyword is executed, as shown below:

/system-property=test:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"system-property\" => \"test\")]' not found",
    "rolled-back" => true
}

The below example issues the appropriate management CLI command to enable the ExampleDS datasource by checking the launch type of the server process (STANDALONE or DOMAIN).

if (result == STANDALONE) of /:read-attribute(name=launch-type)
    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled, value=true)
else
    /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled, value=true)
end-if

Management CLI commands with if-else control flow can be specified in a file, with each command on a separate line in the file. You can then pass the file to the jboss-cli script to be executed non-interactively using the --file parameter.

$ EAP_HOME/bin/jboss-cli.sh --connect --file=CLI_FILE

The management CLI provides a simplified try-catch-finally control flow. It consists of three sets of operations and commands corresponding to the try, catch, and finally blocks. The catch and finally blocks are optional, but at least one of them should be present and only one catch block can be specified.

The control flow begins with execution of the try batch. If the try batch completes successfully, then the catch batch is skipped and the finally batch is executed. If the try batch fails, for example, java.io.IOException, the try-catch-finally control flow will terminate immediately, and the catch batch if it is available will be executed. The finally batch will always execute at the end of the control flow whether the try and catch batches succeeds or fails to execute.

There are four commands that define the try-catch-finally control flow:

The following example either creates or re-creates a datasource and enables it:

try
/subsystem=datasources/data-source=myds:add(connection-url=CONNECTION_URL,jndi-name=java:/myds,driver-name=h2)

catch
/subsystem=datasources/data-source=myds:remove
/subsystem=datasources/data-source=myds:add(connection-url=CONNECTION_URL,jndi-name=java:/myds,driver-name=h2)

finally
/subsystem=datasources/data-source=myds:enable
end-try

The management CLI supports for-done control flow, which allows you to iterate over a collection returned from an operation and execute commands on each item in the collection. You can use for-done statements with the management CLI in interactive or non-interactive mode. for-done statements use the following syntax:

for VARIABLE_NAME in OPERATION
  COMMANDS_TO_EXECUTE
done

The following example iterates over all deployments and displays whether each is enabled or disabled.

for deploymentName in :read-children-names(child-type=deployment)
  if (result == true) of /deployment=$deploymentName:read-attribute(name=enabled)
    echo $deploymentName is enabled.
  else
    echo $deploymentName is disabled.
  end-if
done

Enter done --discard if you want to discard the current for block without executing the commands.

The JBoss EAP management CLI provides the query operation to query a resource. You can use the :read-resource operation to read all attributes for a resource. If you want to list only selected attributes, you can use the :query operation.

For example, to see the list of name and enabled attributes, use the following command:

/deployment=jboss-modules.jar:query(select=["name","enabled"])

The following response shows that the operation was successful. The name and enabled attributes are listed for the jboss-modules.jar deployment.

{
    "outcome" => "success",
    "result" => {
        "name" => "jboss-modules.jar",
        "enabled" => true
    }
}

You can also query across multiple resources, for example, list the name and enabled attributes of all deployments, using a wildcard:

/deployment=*:query(select=["name","enabled"])

The following response shows that the operation was successful. The name and enabled attributes of all deployments are listed.

{
     "outcome" => "success",
     "result" => [
         {
             "address" => [("deployment" => "helloworld.war")],
             "outcome" => "success",
             "result" => {
                 "name" => "helloworld.war",
                 "enabled" => true
             }
         },
         {
             "address" => [("deployment" => "kitchensink.war")],
             "outcome" => "success",
             "result" => {
                 "name" => "kitchensink.war",
                 "enabled" => true
             }
         },
         {
             "address" => [("deployment" => "xyz.jar")],
             "outcome" => "success",
             "result" => {
                 "name" => "xyz.jar",
                 "enabled" => false
             }
         }
     ]
 }

The :query operation also filters relevant objects. For example, to view the name and enabled attribute values for deployments with enabled as true.

/deployment=*:query(select=["name","enabled"],where=["enabled","true"])

The following response shows that the operation was successful. The name and enabled attribute values for deployments with enabled as true are listed.

{
     "outcome" => "success",
     "result" => [
         {
             "address" => [("deployment" => "helloworld.war")],
             "outcome" => "success",
             "result" => {
                 "name" => "helloworld.war",
                 "enabled" => true
             }
         },
         {
             "address" => [("deployment" => "kitchensink.war")],
             "outcome" => "success",
             "result" => {
                 "name" => "kitchensink.war",
                 "enabled" => true
             }
         }
     ]
 }

Instead of printing output from a management CLI operation to the terminal, you can redirect the output to a file or to another command.

Redirect Output to a File

Use the > operator to redirect output from a management CLI operation to a file on the file system.

:read-resource > myfile.txt

Use the >> operator to redirect output from a management CLI operation and append it to a file on the file system.

:read-resource >> myfile.txt

Redirect Output to a Command

Use the | operator to redirect output from a management CLI operation to the grep command to search output for a regular expression match. Currently, grep is the only supported command for the | operator.

/subsystem=logging/log-file=server.log:read-log-file | grep Deployed
        "2018-03-06 09:48:02,389 INFO  [org.jboss.as.server] (management-handler-thread - 5) WFLYSRV0010: Deployed \"jboss-helloworld.war\" (runtime-name : \"jboss-helloworld.war\")",

JBoss EAP supports the use of preset element and property expressions in the management CLI. These expressions will be resolved to their defined values during the execution of the command.

You can substitute expressions for the following properties:

By default, the management CLI performs property substitution for every line except for argument or parameter values. Argument and parameter values are resolved in the server at runtime. If you require property substitution for argument or parameter values to occur in the management CLI and have it send the resolved values to the server, complete the following steps.

This element only affects operation request parameter values and command argument values. It does not impact the rest of the command line. This means system properties present on the command line will be resolved during the parsing of the line regardless of what the value of resolve-parameter-values element is, unless it is a parameter/argument value.

System property values used in management CLI commands must have already been defined in order to be resolved. You must either pass in a properties file (--properties=/path/to/file.properties) or property value pairs (-Dkey=value) when starting your management CLI instance. The properties file uses a standard KEY=VALUE syntax.

Property keys are denoted in your management CLI commands using the ${MY_VAR} syntax, for example:

/host=${hostname}/server-config=${servername}:add(group=main-server-group)

See Configuring the Management CLI for other jboss-cli.xml configuration options.

You can define aliases for the CLI commands and operations during a CLI session using the alias command.

The following example creates a new CLI command alias named read_undertow to read the resources in the undertow subsystem using the alias command:

alias read_undertow='/subsystem=undertow:read-resource'

To test the creation of read_undertow alias, type the alias name in the management CLI:

read_undertow

The result will be:

{
    "outcome" => "success",
    "result" => {
        "default-security-domain" => "other",
        "default-server" => "default-server",
        "default-servlet-container" => "default",
        "default-virtual-host" => "default-host",
        "instance-id" => expression "${jboss.node.name}",
        "statistics-enabled" => false,
        "buffer-cache" => {"default" => undefined},
        "configuration" => {
            "filter" => undefined,
            "handler" => undefined
        },
        "server" => {"default-server" => undefined},
        "servlet-container" => {"default" => undefined}
    }
}

To view a list of all available aliases, use the alias command:

alias

The result will be:

alias read_undertow='/subsystem=undertow:read-resource'

To remove an alias, use the unalias command:

unalias read_undertow

JBoss EAP contains the runtime configuration .jbossclirc file, which helps you to initialize the environment when a new session is launched. This file is located in EAP_HOME/bin/ directory. The example provided in the file can be used as a template for user-specific environment setup. The .jbossclirc file is ideal for storing global CLI variables.

The content of the .jbossclirc file is a list of CLI supported commands and operations. This file is executed when a new management CLI session is launched but before the control is given to the user. If there are system properties specified with --properties argument, then the .jbossclirc file is executed after the properties have been set.

Example .jbossclirc File

set console=/subsystem=logging/console-handler=CONSOLE

The following locations will be checked for the presence of the .jbossclirc file in the following order:

Using the Set Command

You can define a certain path of the server model to a variable using the set command. For example:

set s1=/host=master/server=server-one

This is useful in a managed domain as you can include references to host and profiles using variables to easily replicate scripts on different servers. For example:

$s1/subsystem=datasources/data-source=ExampleDS:test-connection-in-pool

Using the Unset Command

You can remove the variable by using the unset command:

unset prod_db

Using the jbossclirc File

To use the variable across CLI session, you can include these variables in the .jbossclirc file. This file is located in the EAP_HOME/bin/ directory.

For example:

set s1=/host=master/server=server-one
set s2=/host=master/server=server-two

Now, restart the management CLI and issue a set command to check the available variables:

set

The output will be:

s1=/host=master/server=server-one
s2=/host=master/server=server-two

The variables may appear in any part of a command line and resolved during the command line parsing phase. In this example, the prod_db variable will be resolved to a datasource:

$prod_db/statistics=jdbc:read-resource

Using the Echo Command

Use the echo command to check the value of a variable:

echo $prod_db

The output will be:

/subsystem=datasources/data-source=ExampleDS

Example

The following general examples show where the variables may appear and that the entire command line may consist of variables:

$prod_db:$op($param=$param_value)
$cmd --$param=$param_value

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

jms-queue add --queue-address=QUEUE_NAME --entries=JNDI_NAME

jms-topic add --topic-address=TOPIC_NAME --entries=JNDI_NAME

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

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

deployment deploy-file /path/to/DEPLOYMENT.war

deployment disable /path/to/DEPLOYMENT.war

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

deployment disable-all

You can use the attachment display command to display the contents of an attachment returned from a management operation. This applies to any management operation that returns the attached-streams response header.

For example, the following operation returns the server.log file attached as a stream.

/subsystem=logging/log-file=server.log:read-attribute(name=stream)
{
    "outcome" => "success",
    "result" => "f61a27c4-c5a7-43ac-af1f-29e90c9acb3e",
    "response-headers" => {"attached-streams" => [{
        "uuid" => "f61a27c4-c5a7-43ac-af1f-29e90c9acb3e",
        "mime-type" => "text/plain"
    }]}
}

You can use the attachment display command to display the contents of the stream returned form this operation to the console.

attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)

This outputs the contents of the server.log file to the console.

ATTACHMENT 3480a327-31dd-4412-bdf3-f36c94ac4a09:
2018-10-18 09:19:37,082 INFO  [org.jboss.modules] (main) JBoss Modules version 1.8.6.Final-redhat-00001
2018-10-18 09:19:37,366 INFO  [org.jboss.msc] (main) JBoss MSC version 1.4.5.Final-redhat-00001
2018-10-18 09:19:37,380 INFO  [org.jboss.threads] (main) JBoss Threads version 2.3.2.Final-redhat-1
2018-10-18 09:19:37,510 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: JBoss EAP 7.2.0.GA (WildFly Core 6.0.9.Final-redhat-20181015) starting
...

To show the schema information for the :product-info command:

:read-operation-description(name=product-info)

To display the schema version, execute an ls command at the management CLI root and look for the management-*-version values:

...
management-major-version=4
management-micro-version=0
management-minor-version=1
...

:product-info

{
    "outcome" => "success",
    "result" => [{"summary" => {
        "host-name" => "HOST_NAME",
        "instance-identifier" => "INSTANCE_ID",
        "product-name" => "JBoss EAP",
        "product-version" => "7.2.0.GA",
        "product-community-identifier" => "Product",
        "product-home" => "EAP_HOME",
        "standalone-or-domain-identifier" => "OPERATING_MODE",
        "host-operating-system" => "OS_NAME",
        "host-cpu" => {
            "host-cpu-arch" => "CPU_ARCH",
            "host-core-count" => CORE_COUNT
        },
        "jvm" => {
            "name" => "JAVA_VM_NAME",
            "java-version" => "JAVA_VERSION",
            "jvm-version" => "JAVA_VM_VERSION",
            "jvm-vendor" => "JAVA_VM_VENDOR",
            "java-home" => "JAVA_HOME"
        }
    }}]
}

Similarly, for a managed domain, you can display the information for a particular JBoss EAP host or server:

/host=HOST_NAME:product-info

/host=HOST_NAME/server=SERVER_NAME:product-info

deployment enable DEPLOYMENT.war

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

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

command-timeout get

The value returned is in seconds. A value of 0 means no timeout.

reload --host=HOST_NAME

reload --host=HOST_NAME --admin-only=true

reload

module remove --name=MODULE_NAME

You can use the attachment save command to save the contents of an attachment returned from a management operation to a file. This applies to any management operation that returns the attached-streams response header.

For example, the following operation returns the server.log file attached as a stream.

/subsystem=logging/log-file=server.log:read-attribute(name=stream)
{
    "outcome" => "success",
    "result" => "f61a27c4-c5a7-43ac-af1f-29e90c9acb3e",
    "response-headers" => {"attached-streams" => [{
        "uuid" => "f61a27c4-c5a7-43ac-af1f-29e90c9acb3e",
        "mime-type" => "text/plain"
    }]}
}

You can use the attachment save command to save the contents of the stream returned form this operation to a file.

attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=log-output.txt

This saves the contents of the server.log file to EAP_HOME/bin/log-output.txt.

command-timeout set TIMEOUT_VALUE

The value is set in seconds. A value of 0 means no timeout.

deployment undeploy DEPLOYMENT.war

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

The host must be reloaded in order for the changes to take effect.

You can upload a local file as an attachment to management operations that accept file streams. For example, the following management CLI command uses the input-stream-index option to upload the contents of a local file to an exploded deployment.

/deployment=DEPLOYMENT_NAME.war:add-content(content=[{target-path=/path/to/FILE_IN_DEPLOYMENT, input-stream-index=/path/to/LOCAL_FILE_TO_UPLOAD}]

For more details on uploading files to a deployment, see the Add Content to an Exploded Deployment section of the Configuration Guide.

/subsystem=logging/log-file=SERVER_LOG_NAME:read-log-file