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.
---------------
I want to start with a hat-tip to Scott Kurz for writing the Stack Overflow answer where I learned about this capability. You can find it here:
https://stackoverflow.com/questions/76466475/how-do-i-view-the-merged-liberty-server-configuration-after-includes-and-configd
This is kind of the answer to a problem and along the way reveals some pretty interesting stuff. The problem is, having created a complex configuration environment with lots of included files and lots of variables (and maybe some paths to include files set by variables), you may wonder what you wound up with. That is, if it all got folded and resolved into a single server.xml file, what would it look like? Did you really get what you wanted?
The server won’t log the ‘resolved’ configuration anywhere and, of course, if you have config file monitoring turned on it could change at any moment anyway. So how can you find out what the result was? Well, Scott’s writeup at the link above describes how to enable and use a REST API to extract the resolved configuration from the server (at the point in time when you call the API anyway).
Sort of. What you’d really like is what the XML file would look like if it was all resolved down. But the REST API gives you back a JSON document. Not so many angle-brackets, lots and lots of curly brackets. But once you get past that you’ll discover that you’ve got a little bit of JSON for all the configuration elements being used by the server. If you’ve assigned an ‘id’ to a configuration element that can make it a lot easier to find it in the JSON. Some elements have to have an id because you refer to it from another element and Liberty will generate an id for anything that doesn’t have one in the XML. This might be a reason to assign an id to configuration elements rather than letting Liberty make one up, just so it is easier to find the matching JSON.
Why is it hard to find a particular element in the JSON? I mean, sure your server configuration is a little complex, but how bad can it be? Well, the thing is, the REST API is going to give you back the ENTIRE configuration, including all the stuff that defaulted. This is the part I found really fascinating.
The first time I looked at the output from this API I was after a particular thing, but got totally sidetracked browsing through all the configuration that the server was using that I DIDN’T set up. Liberty defaults an amazing amount of stuff that you’re probably totally unaware of.
In the end, it isn’t exactly the answer to the problem that I was hoping it would be, but it is pretty close. Give it a shot and let me know if, when you first open the JSON you get back and start paging through it, you don’t say, “Wow…”.