3.5. Management CLI Operations
3.5.1. Display the Attributes of a Resource with the Management CLI
Prerequisites
The read-attribute
operation is a global operation used to read the current runtime value of a selected attribute. It can be used to expose only the values that have been set by the user, ignoring any default or undefined values. The request properties include the following parameters.
Request Properties
name
- The name of the attribute to get the value for under the selected resource.
include-defaults
- A Boolean parameter that can be set to
false
to restrict the operation results to only show attributes set by the user and ignore default values.
Procedure 3.12. Display the Current Runtime Value of a Selected Attribute
Run the
read-attribute
operationFrom the Management CLI, use theread-attribute
operation to display the value of a resource attribute. For more details on operation requests, refer to the topic Section 3.4.8, “Use Operations and Commands in the Management CLI”.[standalone@localhost:9999 /]
:read-attribute(name=name-of-attribute)
read-attribute
operation is the ability to expose the current runtime value of a specific attribute. Similar results can be achieved with the read-resource
operation, but only with the addition of the include-runtime
request property, and only as part of a list of all available resources for that node. The read-attribute
operation is intended for fine-grained attribute queries, as the following example shows.
Example 3.12. Run the read-attribute
operation to expose the public interface IP
read-attribute
to return the exact value in the current runtime.
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address) { "outcome" => "success", "result" => "127.0.0.1" }
resolved-address
attribute is a runtime value, so it is not displayed in the results of the standard read-resource
operation.
[standalone@localhost:9999 /] /interface=public:read-resource { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
resolved-address
and other runtime values, you must use the include-runtime
request property.
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "resolved-address" => "127.0.0.1", "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
The current runtime attribute value is displayed.
3.5.2. Display the Active User in the Management CLI
Prerequisites
The whoami
operation is a global operation used to identify the attributes of the current active user. The operation exposes the identity of the username and the realm that they are assigned to. The whoami
operation is useful for administrators managing multiple users accounts across multiple realms, or to assist in keeping track of active users across domain instances with multiple terminal session and users accounts.
Procedure 3.13. Display the Active User in the Management CLI Using the whoami
Operation
Run the
whoami
operationFrom the Management CLI, use thewhoami
operation to display the active user account.[standalone@localhost:9999 /]
:whoami
The following example uses thewhoami
operation in a standalone server instance to show that the active user is username, and that the user is assigned to theManagementRealm
realm.Example 3.13. Use the
whoami
in a standalone instance[standalone@localhost:9999 /]:whoami { "outcome" => "success", "result" => {"identity" => { "username" => "username", "realm" => "ManagementRealm" }} }
Your current active user account is displayed.
3.5.3. Display System and Server Information in the Management CLI
Prerequisites
Procedure 3.14. Display System and Server Information in the Management CLI
Run the
version
commandFrom the Management CLI, enter theversion
command:[domain@localhost:9999 /]
version
Your application server version and environment information is displayed.
3.5.4. Display an Operation Description using the Management CLI
Prerequisites
Procedure 3.15. Execute the Command in Management CLI
Run the
read-operation-description
operationFrom the Management CLI, useread-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.4.8, “Use Operations and Commands in the Management CLI”.[standalone@localhost:9999 /]
:read-operation-description(name=name-of-operation)
Example 3.14. Display the list-snapshots operation description
list-snapshots
operation.
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots) { "outcome" => "success", "result" => { "operation-name" => "list-snapshots", "description" => "Lists the snapshots", "request-properties" => {}, "reply-properties" => { "type" => OBJECT, "value-type" => { "directory" => { "type" => STRING, "description" => "The directory where the snapshots are stored", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "names" => { "type" => LIST, "description" => "The names of the snapshots within the snapshots directory", "expressions-allowed" => false, "required" => true, "nillable" => false, "value-type" => STRING } } }, "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}}, "read-only" => false } }
The description is displayed for the chosen operation.
3.5.5. Display the Operation Names using the Management CLI
Prerequisites
Procedure 3.16. Execute the Command in Management CLI
Run the
read-operation-names
operationFrom the Management CLI, use theread-operation-names
operation to display the names of the available operations. For more details on operation requests, refer to the topic Section 3.4.8, “Use Operations and Commands in the Management CLI”.[standalone@localhost:9999 /]
:read-operation-names
Example 3.15. Display the operation names using the Management CLI
read-operation-names
operation.
[standalone@localhost:9999 /]:read-operation-names
{
"outcome" => "success",
"result" => [
"add-namespace",
"add-schema-location",
"delete-snapshot",
"full-replace-deployment",
"list-snapshots",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-config-as-xml",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"reload",
"remove-namespace",
"remove-schema-location",
"replace-deployment",
"resolve-expression",
"resolve-internet-address",
"server-set-restart-required",
"shutdown",
"take-snapshot",
"undefine-attribute",
"upload-deployment-bytes",
"upload-deployment-stream",
"upload-deployment-url",
"validate-address",
"validate-operation",
"whoami",
"write-attribute"
]
}
The available operation names are displayed.
3.5.6. Display Available Resources using the Management CLI
Prerequisites
The read-resource
operation is a global operation used to read resource values. It can be used to expose either basic or complete information about the resources of the current or child nodes, along with a range of request properties to expand or limit the scope of the operation results. The request properties include the following parameters.
Request Properties
recursive
- Whether to recursively include complete information about child resources.
recursive-depth
- The depth to which information about child resources should be included.
proxies
- Whether to include remote resources in a recursive query. For example including the host level resources from slave Host Controllers in a query of the Domain Controller.
include-runtime
- Whether to include runtime attributes in the response, such as attribute values that do not come from the persistent configuration. This request property is set to false by default.
include-defaults
- A boolean request property that serves to enable or disable the reading of default attributes. When set to false only the attributes set by the user are returned, ignoring any that remain undefined.
read-resource
operation
From the Management CLI, use the read-resource
operation to display the available resources.
[standalone@localhost:9999 /]:read-resource
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.16. Using the read-resource
operation at the root level
[standalone@localhost:9999 /]:read-resource { "outcome" => "success", "result" => { "management-major-version" => 1, "management-micro-version" => 0, "management-minor-version" => 7, "name" => "localhost", "namespaces" => [], "product-name" => "EAP", "product-version" => "6.4.0.GA", "profile-name" => undefined, "release-codename" => "Janus", "release-version" => "7.5.0.Final-redhat-17", "schema-locations" => [], "core-service" => { "service-container" => undefined, "server-environment" => undefined, "module-loading" => undefined, "platform-mbean" => undefined, "management" => undefined, "patching" => undefined }, "deployment" => undefined, "deployment-overlay" => undefined, "extension" => { "org.jboss.as.clustering.infinispan" => undefined, "org.jboss.as.connector" => undefined, "org.jboss.as.deployment-scanner" => undefined, "org.jboss.as.ee" => undefined, "org.jboss.as.ejb3" => undefined, "org.jboss.as.jaxrs" => undefined, "org.jboss.as.jdr" => undefined, "org.jboss.as.jmx" => undefined, "org.jboss.as.jpa" => undefined, "org.jboss.as.jsf" => undefined, "org.jboss.as.logging" => undefined, "org.jboss.as.mail" => undefined, "org.jboss.as.naming" => undefined, "org.jboss.as.pojo" => undefined, "org.jboss.as.remoting" => undefined, "org.jboss.as.sar" => undefined, "org.jboss.as.security" => undefined, "org.jboss.as.threads" => undefined, "org.jboss.as.transactions" => undefined, "org.jboss.as.web" => undefined, "org.jboss.as.webservices" => undefined, "org.jboss.as.weld" => undefined }, "interface" => { "management" => undefined, "public" => undefined, "unsecure" => undefined }, "path" => { "jboss.server.temp.dir" => undefined, "user.home" => undefined, "jboss.server.base.dir" => undefined, "java.home" => undefined, "user.dir" => undefined, "jboss.server.data.dir" => undefined, "jboss.home.dir" => undefined, "jboss.server.log.dir" => undefined, "jboss.server.config.dir" => undefined, "jboss.controller.temp.dir" => undefined }, "socket-binding-group" => {"standard-sockets" => undefined}, "subsystem" => { "jaxrs" => undefined, "jsf" => undefined, "jca" => undefined, "jmx" => undefined, "threads" => undefined, "webservices" => undefined, "sar" => undefined, "remoting" => undefined, "infinispan" => undefined, "weld" => undefined, "ejb3" => undefined, "transactions" => undefined, "datasources" => undefined, "deployment-scanner" => undefined, "logging" => undefined, "jdr" => undefined, "pojo" => undefined, "jpa" => undefined, "naming" => undefined, "ee" => undefined, "mail" => undefined, "web" => undefined, "resource-adapters" => undefined, "security" => undefined }, "system-property" => undefined } }
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
read-resource
operation towards the specific web subsystem node.
Example 3.17. Expose child node resources from the root node
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource { "outcome" => "success", "result" => { "configuration" => undefined, "enable-lookups" => false, "enabled" => true, "executor" => undefined, "max-connections" => undefined, "max-post-size" => 2097152, "max-save-post-size" => 4096, "name" => "http", "protocol" => "HTTP/1.1", "proxy-name" => undefined, "proxy-port" => undefined, "redirect-port" => 443, "scheme" => "http", "secure" => false, "socket-binding" => "http", "ssl" => undefined, "virtual-server" => undefined } }
cd
command to navigate into the child nodes and run the read-resource
operation directly.
Example 3.18. Expose child node resources by changing directories
[standalone@localhost:9999 /] cd subsystem=web
[standalone@localhost:9999 subsystem=web] cd connector=http
[standalone@localhost:9999 connector=http] :read-resource { "outcome" => "success", "result" => { "configuration" => undefined, "enable-lookups" => false, "enabled" => true, "executor" => undefined, "max-connections" => undefined, "max-post-size" => 2097152, "max-save-post-size" => 4096, "name" => "http", "protocol" => "HTTP/1.1", "proxy-name" => undefined, "proxy-port" => undefined, "redirect-port" => 443, "scheme" => "http", "secure" => false, "socket-binding" => "http", "ssl" => undefined, "virtual-server" => undefined } }
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)
include-runtime
request property exposes additional active attributes, such as the bytes sent and bytes received by the HTTP connector.
Example 3.19. Expose additional and active values with the include-runtime
parameter
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "resolved-address" => "127.0.0.1", "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
3.5.7. Display Available Resource Descriptions using the Management CLI
Prerequisites
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.4.8, “Use Operations and Commands in the Management CLI”.
[standalone@localhost:9999 /]:read-resource-description
The read-resource-description
operation allows the use of the additional parameters.
- Use the
operations
parameter to include descriptions of the resource's operations.[standalone@localhost:9999 /]
:read-resource-description(operations=true)
- 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)
- Use the
recursive
parameter to include recursive descriptions of the child resources.[standalone@localhost:9999 /]
:read-resource-description(recursive=true)
- 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)
- Use the
access-control
parameter to get the information about the permissions the current caller has for this resource.[standalone@localhost:9999 /]
:read-resource-description(access-control=none)
Descriptions of the available resources are displayed.
3.5.8. Reload the Application Server using the Management CLI
Prerequisites
reload
operation to shut down all services and restart the JBoss EAP instance. Note that the JVM itself is not restarted. When the reload
is complete the Management CLI will automatically reconnect.
Example 3.20. Reload the Application Server
[standalone@localhost:9999 /]reload
{"outcome" => "success"}
3.5.9. Shut the Application Server down using the Management CLI
Prerequisites
Procedure 3.17. Shut down the Application Server
Run the
shutdown
operation- From the Management CLI, use the
shutdown
operation to shut the server down via theSystem.exit(0)
system call. For more details on operation requests, refer to the topic Section 3.4.8, “Use Operations and Commands in the Management CLI”.- In the standalone mode, use the following command:
[standalone@localhost:9999 /]
shutdown
- In the domain mode, use the following command with the appropriate host name:
[domain@localhost:9999 /]
shutdown --host=master
- To connect to a detached CLI instance and shut down the server, execute the following command:
jboss-cli.sh --connect command=shutdown
- To connect to a remote CLI instance and shut down the server, execute the following command:
[disconnected /] connect IP_ADDRESS [standalone@IP_ADDRESS:9999 /] shutdown
Replace IP_ADDRESS with the IP address of your instance.
Note
--restart=true
argument to the shutdown
command (as shown below) will prompt the server to restart.
[standalone@localhost:9999 /]shutdown --restart=true
The application server is shut down. The Management CLI will be disconnected as the runtime is unavailable.
3.5.10. Configure an Attribute with the Management CLI
Prerequisites
The write-attribute
operation is a global operation used to write or modify a selected resource attribute. You can use the operation to make persistent changes and to modify the configuration settings of your managed server instances. The request properties include the following parameters.
Request Properties
name
- The name of the attribute to set the value for under the selected resource.
value
- The desired value of the attribute under the selected resource. May be null if the underlying model supports null values.
Procedure 3.18. Configure a Resource Attribute with the Management CLI
Run the
write-attribute
operationFrom the Management CLI, use thewrite-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.
Example 3.21. Disable the deployment scanner with the write-attribute
operation
write-attribute
operation to disable the deployment scanner. The operation is run from the root node, using tab completion to aid in populating the correct resource path.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false) {"outcome" => "success"}
read-attribute
operation.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled) { "outcome" => "success", "result" => false }
read-resource
operation. In the following example, this particular configuration shows the scan-enabled
attribute is now set to false
.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource { "outcome" => "success", "result" => { "auto-deploy-exploded" => false, "auto-deploy-xml" => true, "auto-deploy-zipped" => true, "deployment-timeout" => 600, "path" => "deployments", "relative-to" => "jboss.server.base.dir", "scan-enabled" => false, "scan-interval" => 5000 } }
The resource attribute is updated.
3.5.11. Configure System Properties Using the Management CLI
Procedure 3.19. Configure System Properties Using the Management CLI
- Start the JBoss EAP server.
- Launch the Management CLI using the command for your operating system.For Linux:
For Windows:EAP_HOME/bin/jboss-cli.sh --connect
EAP_HOME\bin\jboss-cli.bat --connect
- Add a system property.The command you use depends on whether you are running a standalone server or a managed domain. If you are running a managed domain, you can add system properties to any or all of the servers running in that domain.
- Add a system property on a standalone server using the following syntax:
/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
Example 3.22. Add a system property to a standalone server
[standalone@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue) {"outcome" => "success"}
- Add a system property to all hosts and servers in a managed domain using the following syntax:
/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
Example 3.23. Add a system property to all servers in a managed domain
[domain@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} }
- Add a system property to a host and its server instances in a managed domain using the following syntax:
/host=master/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
Example 3.24. Add a system property to a host and its servers in a domain
[domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} }
- Add a system property to a server instance in a managed domain using the following syntax:
/host=master/server-config=server-one/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
Example 3.25. Add a system property to a server instance in a managed domain
[domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue) { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}} }
- Read a system property.The command you use depends on whether you are running a standalone server or a managed domain.
- Read a system property from a standalone server using the following syntax:
/system-property=PROPERTY_NAME:read-resource
Example 3.26. Read a system property from a standalone server
[standalone@localhost:9999 /] /system-property=property.mybean.queue:read-resource { "outcome" => "success", "result" => {"value" => "java:/queue/MyBeanQueue"} }
- Read a system property from all hosts and servers in a managed domain using the following syntax:
/system-property=PROPERTY_NAME:read-resource
Example 3.27. Read a system property from all servers in a managed domain
[domain@localhost:9999 /] /system-property=property.mybean.queue:read-resource { "outcome" => "success", "result" => { "boot-time" => true, "value" => "java:/queue/MyBeanQueue" } }
- Read a system property from a host and its server instances in a managed domain using the following syntax:
/host=master/system-property=PROPERTY_NAME:read-resource
Example 3.28. Read a system property from a host and its servers in a domain
[domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:read-resource { "outcome" => "success", "result" => { "boot-time" => true, "value" => "java:/queue/MyBeanQueue" } }
- Read a system property from a server instance in a managed domain using the following syntax:
/host=master/server-config=server-one/system-property=PROPERTY_NAME:read-resource
Example 3.29. Read a system property from a server instance in a managed domain
[domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:read-resource { "outcome" => "success", "result" => { "boot-time" => true, "value" => "java:/queue/MyBeanQueue" } }
- Remove a system property.The command you use depends on whether you are running a standalone server or a managed domain.
- Remove a system property from a standalone server using the following syntax:
/system-property=PROPERTY_NAME:remove
Example 3.30. Remove a system property from a standalone server
[standalone@localhost:9999 /] /system-property=property.mybean.queue:remove {"outcome" => "success"}
- Remove a system property from all hosts and servers in a managed domain using the following syntax:
/system-property=PROPERTY_NAME:remove
Example 3.31. Remove a system property from all hosts and servers in a domain
[domain@localhost:9999 /] /system-property=property.mybean.queue:remove { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} }
- Remove a system property from a host and its server instances in a managed domain using the following syntax:
/host=master/system-property=PROPERTY_NAME:remove
Example 3.32. Remove a system property from a host and its instances in a domain
[domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:remove { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => { "server-one" => {"response" => {"outcome" => "success"}}, "server-two" => {"response" => {"outcome" => "success"}} }}}} }
- Remove a system property from a server instance in a managed domain using the following syntax:
/host=master/server-config=server-one/system-property=PROPERTY_NAME:remove
Example 3.33. Remove a system property from a server in a managed domain
[domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:remove { "outcome" => "success", "result" => undefined, "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}} }
Note
redacted
when output via logging. This improves security by avoiding having passwords output in plain text in log files.
3.5.12. Create a New Server with the Management CLI
master
and adds it to clustered-server-group
:
[domain@localhost:9999 /] /host=master/server-config=clustered-server-1:add(group=clustered-server-group)