Using variables in the CLI script

This post is older than a year. Consider some information might not be accurate anymore.

JBoss can use variables (passed as parameters) in the CLI script. This post describes the details behind it. If the parameter is not passed, it can used the given default.

Expression

Expressions can be used in the XML and CLI configuration.

Usage of port-offset expression in standalone.xml

<socket-binding-group name="standard-sockets" default-interface="public"
 port-offset="${jboss.socket.binding.port-offset:0}">

${jboss.socket.binding.port-offset:0} is a Beanshell expression which means, unless the jboss.socket.binding.port-offset is set, it evaluates to 0 so to standard sockets.

To pass the property as argument

standalone.sh -Djboss.socket.binding.port-offset=100

Using properties file

The parameters can also be passed in a properties file.

JBoss provides the runtime argument for standalone and domain mode

-P <url>
-P=<url>
--properties=<url>

See also Reference of Switches and Arguments to pass at Server Runtime.

Content of custom.properties

test-port=17070

The notation in the CLI script is "${test-port}".

Start JBoss with properties file

# short
domain.sh -P=custom.properties
# full
domain.sh --properties=custom.properties

Use expression in CLI

Check with operation read-resource-description if expressions are allowed.

Check expression capability

If you want to use an expression, you should check if the expression capability is given.

[domain@localhost:9999 /] /socket-binding-group="standard-sockets"/socket-binding="http":read-resource-description > C:\TEMP\jboss-out.txt

This will give you this output (shortened)

{
    "outcome" => "success",
    "result" => {
        "description" => "Configuration information for a socket.",
        "access-constraints" => {"sensitive" => {"socket-config" => {"type" => "core"}}},
        "attributes" => {
            "port" => {
                "type" => INT,
                "description" => "Number of the port to which the socket should be bound.",
                "expressions-allowed" => true,
                "nillable" => true,
                "default" => 0,
                "min" => 0L,
                "max" => 65535L,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "all-services"
            },
     #...
}

For the port attribute "expressions-allowed" => true is the proof.

Testing

We create a new socket binding group and check if the port has an expression instead of the normal value.

[domain@localhost:9999 /] /socket-binding-group="test-sockets":add(default-interface="public")
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
[domain@localhost:9999 /] /socket-binding-group="test-sockets"/socket-binding="http":add(port="${test-port:7070}")
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
[domain@localhost:9999 /] /socket-binding-group="test-sockets"/socket-binding="http":read-resource
{
    "outcome" => "success",
    "result" => {
        "client-mappings" => undefined,
        "fixed-port" => false,
        "interface" => undefined,
        "multicast-address" => undefined,
        "multicast-port" => undefined,
        "name" => "http",
        "port" => expression "${test-port:7070}"
    }
}