andy, if you use tomcat and define your own <Context> sections in server.xml, then make sure that you use the
<Context antiJARLocking="true" option. Otherwise you will might get jar locks if you use manual resource loading from jars in your code. I had this while serving JSF facelets from a shared jar... LieGrue, strub --- On Fri, 12/3/10, David Blevins <[email protected]> wrote: > From: David Blevins <[email protected]> > Subject: Re: ClassLoader File Locking Issues Fixed > To: [email protected], [email protected] > Date: Friday, December 3, 2010, 5:13 PM > On Fri, Dec 3, 2010 at 6:38 AM, Andy > <[email protected]> > wrote: > > Fixed (Possibly a Windows only issue) ClassLoader jar > file locking issues > > which were caused by several factors. > > > > 1. ClassLoaderUtil was using wrong key to remove and > close cached jar files, > > so added a first (most common) and fall-back strategy > to create a valid > > removal key. Also added private method to close jar > file loaders. > > Careful with the jar file close technique. I did some > experimentation > with that a few years ago and I seem to recall that closing > it means > it can never again be used. The form of the "never > again" I can't > remember. We might have issues though in embedded > environments where > we don't really control the classloaders. > > Anyway, something to check into. > > I know we had this working at one point. Grab the 3.0 > final binary > and try a redeploy on your windows machine and see if that > works. > Might be we have added something in between then and now > that is > getting in the way of windows redeploy working. > > > -David >
