Hello and Happy New Year to you all!
As a followup to Kelvin's post on the topic, I thought I'd expand on some of the trials and tribulations we had adopting a new Java framework.
We've been developing all our most recent Java applications in Struts2. This has brought both tears and laughter but among the biggest problems we faced was that once we'd deployed a few of our apps to our live Tomcat server we realised that we couldn't deploy new a version without shutting down the entire instance, and therefore making all our other apps unavailable at the same time. Yikes!
It turned out that Spring, which we use for dependency injection, was holding onto a couple of our jar files even when we were undeploying the application. We'd seen this on some Windows development machines before but not on Linux or our Solaris deployment machines. This time however, the problem didn't occur at all under Windows, about half the time on Linux and 100% of the time on Solaris.
The way we'd dealt with this previously was to get the Windows-based developers to add
antiJARLocking="true" to a hard-coded Context in their server.xml which keeps the problem nice and localised.
That wouldn't work for our live servers since, as the documentation says, "applications that are outside the appBase for the Host will cause the application to be deleted on Tomcat shutdown." which means that for our configuration each time we stopped Tomcat would result in a number of applications being completely deleted!
We eventually solved the problem by writing application-specific META-INF/context.xml files that specified "
antiResourceLocking=true". This means that we can now deploy new versions of our applications and shut down our server without it deleting everything.
This was a reasonably pesky bug to track down since of course I couldn't use my local machine (where the bug didn't appear) or any of our standard development Tomcat instances since I could very easily be deleting people's applications every time I restarted the server. Lesson learnt though and we'll be paying more attention to the deployment configurations we use in future!