Server/Host Name Cannot Be Set Via Properties

[Marvin Geitner]

Hello all.

I have set up a domain with a domain controller as load balancer and behind it two servers as hosts. I am now trying via Docker and the properties jboss.host.name and jboss.server.name to set the names of the hosts via the host.xml. I proceed as follows.

Start Command: /opt/jboss/wildfly/bin/domain.sh [...] -Djboss.server.name=domain-controller

host.xml:
<host xmlns="urn:jboss:domain:20.0" name="${jboss.server.name}">[...]
<servers>
    <server name="${jboss.server.name}" group="balancer-group" auto-start="true"/>
</servers>

Obviously, however, the property is not evaluated, because the server is then started with the name ${jboss.server.name}. Neither this setting, nor another one, e.g. via jboss.host.name, helped. Also about an environment variable and the env. prefix it had no effect.

I am surprised about this, because other properties can be resolved via an expression. For example jboss.bind.address.management in the host.xml.

Is this not supported for the server name? Can someone help me here?

Thanks and greetings
Marvin

[Bartosz Baranowski]

It should work: https://docs.wildfly.org/29/Admin_Guide.html#host-controller-configuration
Out of curiosity, can you add default to those properties?

[Marvin Geitner]

I've also read the documentation (the only difference is that I'm still using version 28).

If I use a default, the result is the same. The entire expression is not resolved, it is then simply set, for example, "${jboss.server.name:default}" as the server name.

[Brian Stansberry]

The name management object that the xml attribute in the server element configures does not support expression resolution. Typically the value of 'name' attributes in the xml become part of the address of a management resource (e.g., for this case, in CLI syntax, /host=host-a/server=a-1) and management resource addresses do not allow expression resolution in any of their parts. They must be fixed values, as their values must be known before expression resolution is performed.

[Marvin Geitner]

Ok I understand that. This is a bit unfavorable for a general definition for Docker containers, so that only a single image can be used and configured from the outside (for hosts), but it is sufficient for my case. Thank you.

[Brian Stansberry]

In case it helps, the value of the server element's 'name' need not affect how the server identifies itself to the outside world for normal non-administrative purposes. You can configure the HostController to pass values into the server process, e.g. to set the jboss.node.name system property, the value of which does affect how the server is identified externally for non-administrative purposes (e.g. in clustering, transaction management). Those values can be externalized and controlled using expressions. The host.xml value of the server 'name' attribute controls the value of the jboss.server.name system property in the server process, but if that property is *directly* controlling externally visible non-administrative behavior, that's a bug. (I say 'directly' because if the jboss.node.name property is not set, then the default value is the same as what's used for jboss.server.name.)  The 'name' attribute here just controls the address used when managing the server via the CLI etc.

For the management aspect I don't think the server name part of the address needs to be unique across hosts. The address as a whole needs to be unique, but the address includes the /host=??? part, and the value of ??? can be externally controlled, via the jboss.host.name or jboss.qualified.host.name system properties or via the HOSTNAME env variable.

For an example of all this, say we have this server config:

        <server name="server-one" group="main-server-group">
            <system-properties>
                <property name="jboss.node.name" value="${host-qualifier}-server-one" boot-time="true"/>
            </system-properties>
        </server>

And we launch the HC:

bin/domain.sh -Dhost-qualifier=example

You can then use the CLI to check the value of the jboss.node.name property on the server:

[domain@localhost:9990 /] /host=primary/server=server-one/core-service=platform-mbean/type=runtime:map-get(name=system-properties,key=jboss.node.name)

{

    "outcome" => "success",

    "result" => "example-server-one"

}

Needing to use an arbitrary property like 'host-qualifier' in the expression is unfortunate, as using properties you might already be control would be cleaner (e.g. "${jboss.host.name}-server-one") but that doesn't work. I haven't thought of any workaround that avoids the need to do this.

[Brian Stansberry]

A better example of what I meant would be to be sure the 'name' attribute in the root element in your host.xml is not set, and then the launch would be something like:

bin/domain.sh -Djboss.host.name=example -Dhost-qualifier=example

The property read is then

[domain@localhost:9990 /] /host=example/server=server-one/core-service=platform-mbean/type=runtime:map-get(name=system-properties,key=jboss.node.name)

[Marvin Geitner]

I think I figured it out how to solve my problem. I removed the name attribute in the root element of host.xml and set the name attribute of the <server> element to the same value among the hosts. Additionally, I have set the host name of the server via -Djboss.host.name. The respective host then registers itself via this value. This then allowed me to maintain the configuration for the hosts within a host.xml.

One thing I noticed. When I create the following for two hosts, only the value of one host is displayed via the GUI, even though the values of the properties are different (if I let the respective host log them, the values are correct). Is probably implemented internally via Key-Value and since I now have two hosts with the same value of the attribute, the other value is swallowed:
<servers>
        <server name="server" group="main-server-group">
            <system-properties>
                <property name="server.name" value="${jboss.host.name}"/>
            </system-properties>
        </server>
</servers>

[Brian Stansberry]

Glad to hear you got it working. I've been out on vacation.

About the UI issue, can you file a bug report at https://issues.redhat.com/projects/HAL?

Thanks,

Brian

[Marvin Geitner]

Done: https://issues.redhat.com/browse/HAL-1885