tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TomK <>
Subject Re: JAR locking / Tomcat 5.5.4 / Windows
Date Thu, 13 Jan 2005 16:22:38 GMT
Thanks very much, I'll check the latest version out and post my results, in case anyone else
has this issue.
That I find myself saying "In case anyone else has this issue" is somewhat amazing to me.
1) Hardly anyone is using Windows as their deployment environment for Tomcat.   (I probably
wouldn't be either, if I had a choice.)
2) Those using Windows as the deploy environment aren't concerned about re-deploying applications,
and are content to simply restart the server, so resource locking is not an issue.
3) Everyone can properly edit the context.xml file, except me and 5 other people on this list.
There have been quite a few posts to this list, as well as bugs opened in bugzilla reporting
JAR locking (with versions 5.0.x, 5.5.x).   I'm a bit disheartened by the earlier replies.
  Either the bug was closed as "invalid", or the reply was "Get yourself a better operating
system", or "You aren't doing it right".     Given the unlikely nature of #3 above, it seems
much more likely that this is indeed a bug.    I hope it has been fixed.

Dominik Drzewiecki <> wrote:
Siarhei Dudzin wrote:
> Did you find a solution?

FYI it has been fixed on 17/12/2004 and the latest CVS version does not 
suffer from the nasty jar locking.
The root of the problem was the JasperLoader locking (using cached 
getResourceAsStream()) the jars containing jsp tag libraries.
It works for me. Please do give it a spin and test for yourselves. 
BTW, there seems to be 5.5.7 distro coming soon.


> On Tue, 4 Jan 2005 15:27:56 -0800 (PST), TomK
> wrote:
>> I've been following the recent threads regarding JAR locking with 
>> Tomcat 5.x on Windows platforms. A few people mentioned they had been 
>> able to get either the antiJARLocking or antiResourceLocking attributes 
>> to work, so I've spent quite a bit of time trying out different 
>> scenarios and configurations, under the impression that I must be 
>> missing something simple.....however, I've not yet found a situation 
>> where either attribute has any effect on deploy/undeploy.

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message