commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Peterson <stevep...@zpfe.com>
Subject RE: [configuration] configuration breaks tomcat autodeploy
Date Tue, 06 Apr 2004 21:41:13 GMT
Daniel -- thanks for the idea on the jar sharing.  Unfortunately, the 
WEB-INF/lib directory of this app is the only place that the 
commons-configuration-1.0-dev-3.jar appears, so I'm inclined to think that 
this isn't the problem.

S

At 05:56 PM 4/5/2004 -0700, Daniel Huang wrote:

>Hi Steve,
>
>That's what I thought.
>
>I think it has something to do with the way Windows handles file sharing and
>locking. When you have multiple applications which happen to use same name
>jar files (in my case, I have multiple applications all using struts.jar and
>validation.jar), even though each app has its own struts.jar file under
>webapps/appX/WEB-INF/lib, Windows still returns a sharing violation error
>when you try to delete those same name jar files (Just try delete the files
>from a file browser and you will know). Therefore, Tomcat is not able to
>completely undeploy or remove an application.
>
>You might want to try a possible workaround that I still didn't get a chance
>yet to verify.
>First, locate all configuration.jar files under $CATALINA_HOME.
>Then rename them so that each has a unique name.
>I hope by doing so it will make Windows understand that these files are not
>shared and suppress the sharing violation error.
>
>As I said, I haven't verified if this will work. So please let me know how
>it goes if you try this.
>
>Regards,
>Daniel
>
>-----Original Message-----
>From: Steve Peterson [mailto:stevep-hv@zpfe.com]
>Sent: Monday, April 05, 2004 1:27 PM
>To: Jakarta Commons Users List
>Subject: RE: [configuration] configuration breaks tomcat autodeploy
>
>This is happening on Windows XP, on Sun JDK 1.4.2_03.
>
>At 09:58 PM 4/4/2004 -0700, Daniel Huang wrote:
>
> >Are you running Tomcat on NT or unix/linux?
> >
> >-----Original Message-----
> >From: Eric Pugh [mailto:epugh@upstate.com]
> >Sent: Saturday, April 03, 2004 10:05 AM
> >To: Jakarta Commons Users List
> >Subject: RE: [configuration] configuration breaks tomcat autodeploy
> >
> >What classes in Configuration are you using?  PropertiesConfiguration.java
> >etc?
> >
> >Eric
> >
> > > -----Original Message-----
> > > From: Steve Peterson [mailto:stevep-hv@zpfe.com]
> > > Sent: Saturday, April 03, 2004 4:59 PM
> > > To: Jakarta Commons Users List
> > > Subject: Re: [configuration] configuration breaks tomcat autodeploy
> > >
> > >
> > > To clarify my message, the only jar left after Tomcat undeploys my app
>is
> > > the _configuration_ jar.
> > >
> > > At 08:50 AM 4/3/2004 -0600, you wrote:
> > >
> > > >I've just integrated the 0331 build of collections into my webapp and
>am
> > > >running into a minor glitch.  I deploy in Tomdat 5.0.18 with
> > > >autodeploy.  Prior to integrating collections I could do autodeploys by
> > > >dropping a new war file into Tomcat's appBase.
> > > >
> > > >After integrating collections, and only if I invoke the collections
>api,
> > > >autodeploy no longer works.  Inspecting the deployment directory for my
> > > >application, the only file left is the collections jar in
> > > WEB-INF/lib, and
> > > >java.exe that is running Tomcat looks like it still has the file
> > > open.  My
> > > >hypothesis is that some file in the jar is being referenced and
> > > not being
> > > >closed.
> > > >
> > > >I tried expanding the jar into the WEB-INF/classes folder to
> > > force the VM
> > > >to read the file individually, but unfortunately the problem
> > > doesn't occur
> > > >in that deployment configuration.
> > > >
> > > >I'm out of ideas on how to run this down.  I know I'll get complaints
>on
> > > >Monday from the other developers on the project about autodeploy
> > > breaking,
> > > >so any help would be appreciated.
> > > >
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message