sampa : colin’s blog

Bye the way, you can look at my posts on the Spring’s mailling list for more details on that problem (assuming it is indeed what I think it is).

http://search.gmane.org/search.php?query=&email=gpoirier16%40globetrotter.net&group=gmane.comp.java.springframework.devel&sort=date

It’s a tough call as to what’s going on. It’s definitely Windows that’s preventing me from manually deleting the directory while TomCat is running, but presumably that’s just because they’re still in use by TomCat, and locked.

I just tried a test now with one app, which uses Spring and Hibernate. Although other times, I’ve seen as many as 5 or 6 jars held onto, this time it’s just ehcache.jar, and this is consistent across multiple attempts.

When I do an undeploy (or hot-redeploy) in JBoss 4.0.2, the same jar is also not released (and JBoss even puts out a warning that the temp expanded dir is only going to be killed on the next restart). But because JBoss _does_ use a separate differently named location for each deploy/redeploy, the redeploy doesn’t fail, as it doesn’t have to write on top of the old jar.

What is interesting is that Resin has absolutely no problem redeploying the app, and it even re-uses the same location for the expanded web-app location it dumps the contents of the WAR file to, not resorting to another dir every time like JBoss. I’m not really surprised here; Resin even back in 1999 when I first started using it had excellent hot-redeploy abilities. Resin is in fact even very amenable to not even deploying your app to it as a WAR file. Just point it to your web-app in expanded format in your target build directory, and it will pick up changed classes automatically, and generally being intelligent enough to restart the app itself as needed.

Thanks Carlos, antiJARLocking=true seems to do the trick! I think that should be the default, but it’s better than nothing…

Preventing the jar files to be locked is better than nothing I guess, but the real problem is that the ClassLoader is not garbage collected, which means multiple hot-deploy will provoke an OutOfMemoryError, and possibly hold external resources such has TCP/IP connections or file locks, if any are opened by the webapp rather than the container. If the ClassLoader is not collected, all its classes definition, their static members and dependencies will stay in memory.

On a developement server I guess it’s usually not too much of a problem though, but I would personally avoid hot-deploy on a production server, unless the webapp was carefully tested not to cause such leaks.

The antiJARLocking/antiResourceLocking will only cause a copy of the files to be locked, not the actual files themselves. If you’re doing many redeployments, prepare for 100s of megabytes of (locked) Jars in the Tomcat work directory.

Perhaps you’re using the “classpath*:” pseudo URL prefix to load resources from JAR files. This is broken (in practice) on Win32. (One of the JVM classes, JarURLConnection IIRC will keep a file lock open indefinately)

thanks! really useful… had the same problem with ehcache stopping redeploys. now tomcat redeploys like a dream.

Sorry that the above post did not include the:

…
to
…

It should read:

<context> … </context>
to
<context antiJARLocking="true" antiResourceLocking="true"> … </context>

Colin,

You have a good point. Both the Servlet Spec (2.2+) and Javadocs basically point to what you just said:

Servlet Spec (2.2+):
The getRealPath method takes a String argument and returns a String representation of a file on the local file system to which that path corresponds. The getPathTranslated method computes the real path of the pathInfo of this request.

In situations where the servlet container cannot determine a valid file path for these methods, such as when the web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null.

Javadocs:
This method returns null if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).

This is a real condundrum. Do you know of an alternative to using getRealPath() that *all* servlet/jsp containers will honor?

*downloads CCR: I Put A Spell On You*
*listens*
*sees article relevance*

:/

Thanks for the reply Colin. But the path is not just for classes. I have a Web app that references XML, XSLT templates and media (e.g. images) from the file system and so knowing where it these files are is imperative.

This is the part of Web app development that I love to hate with a passion.

Actually, XML and XSLT should live on the classpath and be read as resources… you shouldn’t really be reading anything contained in the war, and fortunately, there’s never a time where you actually need it explicitly on the file system anyway… Java’s InputStream is flexible enough.

At any j2ee release, they may mandate that wars are not exploded (they’ve hinted at it so far) at which point any code like this breaks, unless you manually explode (and therefore deploy)

thanks alot guys very good job.

Creating the context file didn’t work for me to remove ehcache.jar. What did work was placing an ehcache.xml in the classes directory.