3.5. Management CLI Operations

3.5.1. Display the Attributes of a Resource with the Management CLI

Prerequisites

Summary

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

An advantage of the 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

If you know the name of the attribute that you would like to expose, you can use the 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"
}
The 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
    }
}
To display 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
    }
}
Result

The current runtime attribute value is displayed.

Report a bug

3.5.2. Display the Active User in the Management CLI

Prerequisites

Summary

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

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

Your current active user account is displayed.

Report a bug

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 command

    From the Management CLI, enter the version command: 
    [domain@localhost:9999 /] version
Result

Your application server version and environment information is displayed.

Report a bug

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

The following example shows the method for describing the 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
    }
}
Result

The description is displayed for the chosen operation.

Report a bug

3.5.5. Display the Operation Names using the Management CLI

Prerequisites

Procedure 3.16. Execute the Command in Management CLI

Example 3.15. Display the operation names using the Management CLI

The following example shows the method for describing the 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"
    ]
}
Result

The available operation names are displayed.

Report a bug

3.5.6. Display Available Resources using the Management CLI

Prerequisites

Summary

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.
Execute the Command in Management CLI

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.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
    }
}
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.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
    }
}
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.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
    }
}
Use the recursive parameter to include active values in results

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

[standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
Compared to the previous example, the inclusion of the include-runtime request property exposes additional active attributes, such as the bytes sent and bytes received by the HTTP connector.

Example 3.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
    }
}
Report a bug

3.5.7. Display Available Resource Descriptions using the Management CLI

Prerequisites

Execute the Command in Management CLI

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

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

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

Descriptions of the available resources are displayed.

Report a bug

3.5.8. Reload the Application Server using the Management CLI

Prerequisites

From the Management CLI, use the 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.
For more details on operation requests, see Section 3.4.8, “Use Operations and Commands in the Management CLI”.

Example 3.20. Reload the Application Server

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

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

Appending the --restart=true argument to the shutdown command (as shown below) will prompt the server to restart. 
[standalone@localhost:9999 /]shutdown --restart=true
Result

The application server is shut down. The Management CLI will be disconnected as the runtime is unavailable.

Report a bug

3.5.10. Configure an Attribute with the Management CLI

Prerequisites

Summary

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

Example 3.21. Disable the deployment scanner with the write-attribute operation

The following example uses the 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"}
The results of the operation can be confirmed directly with the read-attribute operation. 
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}
The results can also be confirmed by listing all of the node's available resource attributes with the 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
    }
}
Result

The resource attribute is updated.

Report a bug

3.5.11. Configure System Properties Using the Management CLI

Procedure 3.19. Configure System Properties Using the Management CLI

  1. Start the JBoss EAP server.
  2. Launch the Management CLI using the command for your operating system.
    For Linux: 
    EAP_HOME/bin/jboss-cli.sh --connect
    For Windows: 
    EAP_HOME\bin\jboss-cli.bat --connect
  3. Add a system property.
    The command you use depends on whether you are running a standalone server or a managed domain. If you are running a managed domain, you can add system properties to any or all of the servers running in that domain.
    • Add a system property on a standalone server using the following syntax: 
      /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

      Example 3.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"}}}}}}
}
  4. Read a system property.
    The command you use depends on whether you are running a standalone server or a managed domain.
    • Read a system property from a standalone server using the following syntax: 
      /system-property=PROPERTY_NAME:read-resource

      Example 3.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"
    }
}
  5. Remove a system property.
    The command you use depends on whether you are running a standalone server or a managed domain.
    • Remove a system property from a standalone server using the following syntax: 
      /system-property=PROPERTY_NAME:remove

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

Any system property which contains the text password (regardless of case) is replaced with the text redacted when output via logging. This improves security by avoiding having passwords output in plain text in log files.
Report a bug

3.5.12. Create a New Server with the Management CLI

The following example creates a new server on the host master and adds it to clustered-server-group: 
[domain@localhost:9999 /] /host=master/server-config=clustered-server-1:add(group=clustered-server-group)
Report a bug