Comments on: I Put A Spell On You, Because you’re mine: Aka Why is TomCat Holding Onto Jars?

by: James Carr » Blog Archive » “Please Tomcat, I beg of you! Please release my jars!”

Sun, 10 Jun 2007 15:24:07 +0000

[…] Luckily, a little googling yielded this fine solution, which I am sharing in hopes google picks this post up for other people, as it took me looking through 3 or 4 pages of google results to find it. […]

by: Al

Mon, 13 Feb 2006 09:36:20 +0000

Best title for a blog entry I’ve seen in some time. BTW, it’s actually a Screamin’ Jay Hawkins song, covered by CCR. Clearly there’s a little bit of the devil spirit of SJH in Tomcat

by: Larry Singer

Fri, 20 Jan 2006 05:31:03 +0000

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.

by: Larry Singer

Fri, 20 Jan 2006 04:43:35 +0000

I have just been investigating this exact problem. I found the reason one of my JARs was being held was that a library was not closing the InputStream to a resource it was loading. I now have ehcache only stuck. I’ll try the context switche suggestion to see if it fixes it.

by: Sex toys

Sat, 10 Dec 2005 15:47:41 +0000

thanks alot guys very good job.

by: Victor Ott

Thu, 17 Nov 2005 17:08:15 +0000

Tomcat hot redeployment: you shouldn’t rely on that very much on productive systems. As others stated before, the memory leakage is tremendous. Even with PermGen memory space set to astronomic values (max=256MB) certain applications can’t be hot redeployed more than 15-17 times in Tomcat. Maybe it is Bill’s revenge?

by: Cris Daniluk

Thu, 03 Nov 2005 05:34:19 +0000

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)

by: Colin Sampaleanu

Sun, 23 Oct 2005 01:29:24 +0000

Unfortunately that may well mean that your app is one such app that needs to always be deployed in expanded form, or on a container that fully expands WAR files…

by: Arron Ferguson

Fri, 21 Oct 2005 22:37:18 +0000

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.

by: Colin Sampaleanu

Fri, 21 Oct 2005 15:29:54 +0000

Realistically the only portable solution is to rely only on loading resources through the classloader, off the classpath, and never expect to be able to call getRealPAth.

Now you do come across web-apps which expressly say they must be installed in expanded form (not WARed), exactly because they do expect to be able to call this method and get a proper result.