I recently looked into ways how to make externalized config work with Tomcat 8.
To release a new version to our production Tomcat, I usually just login via FTP, delete the old webapp/war and upload the new webapp/war. AutoDeploy does the rest. We currently don't use the Tomcat Manager.
Now, i can't have my config be a part of my war anymore. It needs to instead sit on the server in a persistent way (=externalized config). Tomcat seems to make this basically impossible for me. I am now using for my config. In the context, i have a JNDI environment entry that specifies where the workspace folder for this app (which includes config files etc.) is located. I can not hardcode this in my war, because the same war is used for development, production and staging, and the workspace location is different for all of those.
This external context XML works fine, until Tomcat deletes it. If see basically no way, without the manager, to redeploy my war without this file getting deleted. I can't restart the server (our admin does that) and i don't see why i should be forced to shut down the server just to prevent tomcat from deleting my configuration when i delete the old war. This Tomcat behaviour doesn't make any sense for me.
- Some people have suggested to make the config read-only. This doesn't work, because tomcat will not autoDeploy a new war if it cannot delete the config.
- Some people suggest not using autoDeploy. As explained, this would require me to restart tomcat on every deploy or use the manager.
So, what i would like to get more information on:
Do i HAVE to use the manager? Or am i just stupid?
And is the manager capable of deploying a new war without deleting my context?
And why is this stupid behaviour still a thing? I have seen tons of posts of people with this problem, here, on stackoverflow, on the mailing lists. It creates problems for everyone it seems, and i have not seen a proper solution that applies to my situation.