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 defining an application to a server through configuration for that server. But you can also simply add an application to a server by placing the .war or .ear file in the monitored dropins folder (whose location is configurable). Of course you can’t do that if the application needs additional configuration (security roles or whatever) that would be part of the definition of the application. The server has to be able to find everything it needs in the .war or .ear file itself.
The dropins folder is very cool for application developers. Besides requiring no configuration work at all, it is simple to update. Assuming you have monitoring enabled for the dropins folder, the appearance of an application in the folder will cause it to be started. If the file is removed, the application is stopped. And, in kind of a two-step thing, if you replace an existing application file, the application is stopped and then started again using the new file. This eliminated a lot of fuss as you’re developing an application. You never have to remember if you restarted the app after that last update. Whatever is in the file system is what it is being run.
In a production environment you probably will have turned off active monitoring of the dropins folder. You can use a modify command to “rescan” the folder to pick up changes, but should you?
I can see the arguments both for and against. If you have a major application problem that you need to fix right away, being able to just drop in the updated application (and maybe issue a modify command) is probably the fastest way to get that fix into use. If you’ve got some major crisis and have four lines of management looking over your shoulder, the quicker you can get an updated application into use, with the fewest steps for you to forget to do, might be best.
On the other hand, how many applications do you have that really don’t require any additional configuration? And how much do you want to depend on what happens to be in the dropins folder to determine what applications a server starts? Is write access to the dropins folder the same as write access to the server configuration to define an application?
To me (and remember I don’t actually own any production application servers myself, so…) the more “production” a server is, the more you want to be able to know for sure what is happening in it and control changes that are made to it.
Updating an existing application defined in the server configuration is still pretty quick. I think the difference comes with adding a new application to an existing server. It just feels to me like you’d have more controls over updating the server configuration to define a new application that you might over write-access to the dropins folder (and similarly, removing an application seems more controlled by the change to the config than just deleting the file from dropins).
Like so much of the rest of the things we’ve discussed, it really depends on what your own needs are and your own risk assessments. Yet another thing to think about.