This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
Last week we talked about setting environment variables for your server. Some of those might be for use by the JVM or other things, but you might want them to be used in the server configuration itself. If you have an environment variable of HTTP_PORT then you could use that value in the httpEndpoint configuration like this: httpPort=${env.HTTP_PORT}.
You can do the same thing with properties set in bootstrap.properties or as -D system properties in jvm.options (leave out the ‘env’ in the name in that case).
This is all pretty cool because it allows you to have common configuration that is customized by the environment. You could actually do this sort of thing with a lot of the configuration specifics, but then you’d end up with a whole lot of environment variables or properties needing to be specified and what happens if you forget one?
Setting configuration variables can help with this. Suppose you’ve got some configuration element that has an attribute you might want to set to different values sometimes, but you want all the servers to share a common configuration. Liberty will assign a default for the attribute, but if you code the attribute then you have to set it to something. You could have this in server.xml:
<someElement someAttribute=”1”/>
You could change that to look at a property like this:
<someElement someAttribute=”${someAttributeProperty}”/>
But if the property isn’t set, what do you get? Instead you could use a variable defined like this:
<variable someAttributeValue=”1”/>
And then substitute that in like this:
<someElement someAttribute=”${someAttributeValue}”/>
How does that help? Well, it doesn’t, but what if we change it to this:
<variable someAttributeValue=”${someAttributeProperty}” default=”1”/>
Now our configuration attribute will be set to the value specified by the property, unless it isn’t set in which case we get a value of ‘1’.
And so your server.xml could include a file that defines (and sets defaults) for a whole bunch of variables that are possibly used throughout common configuration. Any individual server can override those defaults by setting an environment variable (or a property).
There’s also a way to scope a variable definition for use by a specific configuration element (in case someAttribute is a name that crops up a lot I suppose).
Lots of detail in the Liberty documentation. Trust that more than my syntax above..