Hi. Thanks - yes I realise. Wonderin why tihs has been done? Was the old classloader mechanisms in 5.0.x that broken? Not criticising, just trying to understand the reasoning here.
Also I tried with the antiARLocking="true", but had some very strange behaviours - I could not delete a jar - in order to replace it. Also, when I used the ant JAR task - it replaced the contents of the JAR, however when I attemted to access my web app Exceptions were thrown regarding unexpected end of ZIP/JAR files etc - specifically when the class that was replaced was looked for by the classloader - after which a class not found exception was thrown! I checked the new JAR using different tools and it is fine! Thanks, Carl -----Original Message----- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 23, 2004 1:08 PM To: Tomcat Users List Subject: Re: Tomcat 5.5.4 - classes in classpath not being "released" On Mon, 22 Nov 2004 16:37:39 +0200, Carl Olivier <[EMAIL PROTECTED]> wrote: > Ooppps. > > Sorry -meant 300 seconds! I think this could be improved, but the penalty will stay significant. antiJARLocking prevents locking through usage of getResource on the classloader (where you get a URL to an entry in a JAR, and which would lock the JAR if you carelessly open it - Xerces with Struts does that) is more limited, but less expensive. -- xxxxxxxxxxxxxxxxxxxxxxxxx R�my Maucherat Developer & Consultant JBoss Group (Europe) S�RL xxxxxxxxxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- 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]
