sampa : colin’s blog

I don’t normally like turning to the blogosphere for help, but I can’t for the life of me figure out why TomCat 5.5 refuses to release 4-5 jars from some web-apps when they’re undeployed. It’s like the old CCR song is talking about jars:

I put a spell on you
Because you’re mine.
You better stop
The things that you’re doin’.
I said “Watch out!
I ain’t lyin’, yeah!
I ain’t gonna take none of your
Foolin’ around;
I ain’t gonna take none of your
Puttin’ me down;
I put a spell on you
Because you’re mine.
All right!

This issue happens to me on a couple of machines here, and it’s happened at a client site too. I drop a WAR file into TomCat’s deploy dir, and it deploys the web-app ok (creating a dir with the same name as the WAR file). I then kill the WAR file, or drop in a newer version, and for both cases, TomCat tries to undeploy the old version by deleting the expanded directory. But it continues to hold onto 3-6 of the jars in the WEB-INF/lib directory, so can’t actually kill everything completely. Then it actually gets confused and tries to deploy that directory as a web-app, complaining that there’s no web.xml, which is true since there’s nothing there but some jars in the lib dir.

This is unbelievable frustrating as it essentially kills hot-deploy. I would think it’s something in my environment, however, as I said, it’s happened at a couple of client sites too.

Has anybody else had this issue with TomCat 5.5? This essentially kills hot-redeploy. Instead I have to stop TomCat, kill the left-over expanded dir (if I try while it’s still running Windows complains that the jars in WEB-INF/lib are still in use), and re-start. I can’t find any bugs in the TomCat bug tracker that seem related to this.

Updated 2005-8-23: Carlos Sanchez suggested trying the antiJARLocking config property on the TomCat Context, as described here. This actually seems to do the trick. One way to apply it is to modify the file
    conf/context.xml
in your TomCat install and change
    <context> ...  </context>
to
    <context antiJARLocking="true"> ... </context>

Of course this affects all apps, but I don’t necessarilly see this as a big deal. While it’s supposed to slow things down a bit, I really think this should have been the default.

Alternately, one of the other ways you can set this is inside a
   META-INF/context.xml
file inside your app itself. I guess the only thing that rubs me the wrong way about that is the fact that this is a pretty generic filename that might conflict with another lib that expects a file by that name. On the other hand, the advanatage is that if you know your app is going to have this issue in TomCat, you can just take care ahead of it ahead of time. In any case, this is mostly a dev-time issue (I doubt anybody trusts hot-redeploy in TomCat in production), so the first solution is fine for most people.

(Note when looking at the above XML and that in the comments that the braindead WordPress edit box sanitizer makes all xml tags lowercase. The context element above has an initial uppercase.