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.
---------------
As you start creating more and more server configurations, you’re going to want to consider moving some of the configuration into files that are included into each server’s own server.xml. Although, included files can themselves include other files, so you can nest things. Don’t go crazy with that.
The usual reason to include something is to have common configuration in a common file used by multiple servers. You might also want to have different file permissions for different pieces of the configuration based on who you want to be able to update which bits, but remember any configuration can go in any file, so just because you’ve got a data source definition included doesn’t mean the person with permission to update that file can’t put anything they want in there.
Ok, so where do your included files live? Well, anywhere you like in your file system. Could even be in a file system shared across the sysplex. You can even put a URL in instead of a normal path/filename. Furthermore, you can indicate that an included file is optional. That means if it can’t find the file, it is ok. That might happen if your path to the file includes variables. Maybe your common server.xml includes some server-specific thing and uses the name of the server as part of the path to it. That server-specific thing might not exist for every server because you don’t need it sometimes. That’s ok.
With configuration bits coming from different people, you’ll want to think about how to handle conflicts. Includes are handled in the order they are read. Think of them as essentially inserted right there in the main server.xml. When you include a file you can indicate how to handle any conflicts in this file with things it has already seen. You can choose to ignore any new things, try to merge the conflicting thing with what exists, or completely replace the existing config with the newly included stuff. So, define the security stuff early, then include the data source definitions and ignore any conflicts so the person who can update the data source can’t mess with the earlier-defined security stuff.
You can use variables in server.xml and in included files. You might use them in the path names used to find included files. You can use any environment variables defined in server.env (or STDENV, discussed next week), or properties from bootstrap.properties. You can also use pre-defined variables like server.config.dir and shared.config.dir.
You can also create a configDropins folder for each server which contains two sub-folders called defaults and overrides. These folders are automatically monitored for updates. The files in there are read in alphabetical order (which might matter). Things in the overrides directory take precedence over things found in server.xml (and things it includes), which in turn takes precedence over things found in defaults.
Use of these is, again, tied to file permissions. Who has the authority to update overrides? The actual server configuration (or its included bits)? Who can update the defaults you get for things the server.xml doesn’t specify?
There are loads and loads of ways to make use of all this and you’ll need to consider how you want to organize and manage configuration for your servers to decide how to approach it. Whatever you decide to do initially, set a reminder to periodically review how things are unfolding to see if it still makes sense based on how you’re managing things.