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.
---------------
We’re going to look at two more generic Liberty messages and then I promise we’ll get to some z/OS specific stuff. The first of these is CWWKE0001I which tells you the server is starting. The message includes the server name. Technically the server has kind of already been starting for a little while, but mostly that was spinning up the JVM and some other very very fundamental stuff. This is the point from which the actual server itself is beginning to initialize. The point being that the time stamp for this message might be one to look at if you’re trying to measure startup performance.
Oh sure, the actual time you issued the start command or when the address space itself got created are also interesting times to look at. If you’ve got some issue with initializing the JVM itself you’re going to want to look before this message. But Liberty startup itself really begins with this message and startup delays related to Liberty are most likely going to be after this point in time.
Right away Liberty is going to start processing its configuration which is, of course, located in server.xml. But, as we’ve discussed in earlier posts, you can choose to include other XML files that contain other bits of configuration. You might do this to separate out config that ‘belongs’ to different people/groups or to place config used in common across several servers in a single place. And you can have included files include files themselves. There’s a lot of opportunity here to make a big complicated mess.
To help you figure out what you’ve done to yourself, the server will issue message CWWKG0028A for each included XML file it processes. The message naturally gives you the path and file name of the XML file as it picks it up.
This actually gets you two things. First, obviously, is a list (spread across all instances of this message) of the files that are being included (directly or indirectly) from server.xml. The list shouldn’t be a surprise to you, of course. But it is rather handy to have, all in one place, all the files that are getting picked up. And if it does surprise you by picking up something you didn’t expect…well.
The second thing it gets you is the order things are processed. If you haven’t done anything terribly complicated you probably knew this, but as things get more involved you might wonder. And when you include configuration files you can indicate whether the included stuff is allowed to override stuff it has already seen. So if you’ve got config that does security stuff and then later include a file that configures the same security stuff, differently, you can control whether the second stuff overrides the first or is ignored. Depending where things come from and who has access to change it you might want one or the other. But key to all of this is the order the files are processed in and this sequence of messages will tell you.
So if you make a change to some included file and it doesn’t seem to have any effect, even though you were sure it got processed first…well…maybe go check what got processed before it.