I've seen this written up a lot, but I'm coming up empty on solutions I can apply...
I have Tomcat 5.5.26, running on JDK 1.6.0, under Windows Server 2003 (32-bit). For reasons that are completely beyond my control, we have ONE server that serves for both production and test, with several mission-critical applications running on it as well as a bunch of applications of lower criticality. The applications have been written by several different, essentially noncollaborating, authors, and there is no centralized management of things like JNDI. Prior to this version of Tomcat, there was another version installed, and based on the nonexistent directory names in the system classpath, I think also a previous installation of Glassfish.
I have a new web application to deploy. The web application sends notification e-mails, using JavaMail (javax.mail) 1.4.1. When I undeploy the web application, the javamail .jar file is left behind, held tenaciously by the Tomcat process, and I cannot redeploy without stopping the Tomcat service, which I cannot do because of the critical applications that are running.
Things I Have and Have Not Tried:
* I have tried setting anti-jarlocking on the application - in fact, I set it routinely on my web applications. It doesn't help.
* I have not set anti-resourcelocking, because from what I have read, it interferes with the ability to hot deploy.
We deploy by moving a .war file into the webapps directory and then letting Tomcat auto-unpack the .war file. Minor changes to JSP files and XML files are made by editing the unpacked files; they are later incorporated into another .war file so they get included in the next round of code changes that are deployed. I usually un-deploy by deleting the .war file, but I sometimes use the Tomcat Manager application. I have the same issues regardless of the undeploy method, and regardless of whether or not I stop the web application first.
* I would like to try moving the javamail .jar file to the common or at least the shared libraries in Tomcat, but there are several other web applications that have classes or libraries with "mail" in their names, and I do not know which ones are using javamail, and if they are, what version of javamail they are using. I cannot take the risk of breaking them.
* I don't currently have the leisure (or the computing resources) of setting up a new server, upgrading Tomcat version, etc.
* I have searched high and low, and in vain, for an alternate mail package.
* I haven't found a "close" method for the Session, which I had naively hoped might exist and might free up the shared resource when I was done with it.
* If I set anti-resourcelocking in the application context, that should be limited to just that application, correct? Will it solve the problem? I've seen plenty of posts from others, where it seems it doesn't (at least in the case of javamail; it may work for other leftover .jar files). One person mentioned that once the webapp sends an e-mail, you're basically screwed as far as removing javamail. I've been prohibited from restarting Tomcat during the day, so to try it out I would have to do it at night. My laptop is too overloaded with development tools to install a standalone copy of Tomcat to fool around with.
* Does anyone know of any mail api for Java that doesn't use javamail under the hood?
* Any other suggestions that don't involve a second server? I am resigning myself to a night of working at home tonight, over an abysmally slow VPN.
I don't get it. A whale wearing overalls? How does that even work? It's like a tiny ad wearing overalls.
SKIP - a book about connecting industrious people with elderly land owners