We recently started to integrate JFreeChar 1.0.3 into our web application and we are very pleased with the outcome.
Unfortunately our automated deploy cycle on Tomcat 5.5.20 fails now on the jcommon.jar (1.0.6) file.
While Tomcat undeploys the application all files can be deleted from the container except the jcommon.jar. If Tomcat is not able to delete all files, the undeploy is not complete and a new deploy will fail. We have to shut down Tomcat in order to delete the jcommon jar file.
To isolate the problem I have installed the CeWolf demo war application and the problem is repeatable here as well. (sourceforge.net/project/showfiles.php?group_id=57282 - I am a new user and cannot insert a URL right now.).
To reproduce the problem just open the CeWolf demo page and then try to undeploy the application with the Tomcat Manager. You will notice that Tomcat removes the entry from the application list but if you inspect the webapp folder the application is still there (with on jar file, guess which).
My question: Is this a known problem? If so, are there fixes available or in work?
Currently I am planing to move the jcommon jar file in the Tomcat shared lib folder, but this seems to me is just a workaround and the problem probably is inside the jcommon library.
Undeploy Tomcat fails on JCommon jar
-
- JFreeChart Project Leader
- Posts: 11734
- Joined: Fri Mar 14, 2003 10:29 am
- antibot: No, of course not.
- Contact:
I don't work with web apps enough to understand this problem...is it caused by something that JCommon is doing? Can anyone else shed some light on this?
David Gilbert
JFreeChart Project Leader
Read my blog
Support JFree via the Github sponsorship program
JFreeChart Project Leader


-
- Posts: 2
- Joined: Tue Jan 09, 2007 6:32 pm
Re: Undeploy Tomcat fails on JCommon jar
This is a problem of Tomcat, not JCommon.jar. This solution helped to me:
Tweak Tomcat/conf/context.xml by adding either or both attributes
(antiJARLocking antiResourceLocking) to the <context> tag (set them to "true")
Tweak Tomcat/conf/context.xml by adding either or both attributes
(antiJARLocking antiResourceLocking) to the <context> tag (set them to "true")