Do you know how to set the same when running Tomcat in console mode (from command prompt)?
On Thu, 13 Jan 2005 10:33:15 -0800 (PST), TomK <[EMAIL PROTECTED]> wrote: > Success! I was able to get the antiResourceLocking attribute to finally take > effect with Tomcat 5.5.4. > > The problem is the default Windows install does not set the "Working Path" > (viewable on the Startup/Shutdown tabs of the service manager that sits in > the SysTray). Once I set the working path to the tomcat base directory, and > restarted Tomcat, and deployed the WAR, the application files were copied to > the temp directory and run from there, just as promised. Undeploy works > fine. Interestingly, the directories created in the temp directory aren't > deleted when Tomcat is shutdown, for the same reason: the jar's are locked. > > Dominik -- Regarding your statement that "the latest CVS version does not > suffer from the nasty jar locking." I'll try it out later, but are you > suggesting 5.5.7 will not have JAR locking issues at all, and thus the > antiResourceLocking and antiJARLocking attributes will be unnecessary?? > > thanks > -tk > > TomK <[EMAIL PROTECTED]> wrote: > Thanks very much, I'll check the latest version out and post my results, in > case anyone else has this issue. > > -tk > > 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. > > cheers, > /dd > > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]