Good luck.
Best Regards,
Jason Koeninger J&J Computer Consulting http://www.jjcc.com
Rais Bonny wrote:
Thanks again.
I'll remove the reference to commons-logging from the app and use the one in the common directory.
I have tried to remove the app using the manager app and this is
where the whole thing started - all the files in my WEB-INF/lib
remain locked and that includes some jar files which are part of the
app itself, and some files which belong to struts, etc. What is this shutdown interface? The servlet implements the destroy method and attempts to release all the configuration and other stuff it created, but that still is not enough... Is there a way to tell
tomcat to release everything related to a servlet or web app or
does one need to implement this himself?
Bonny
-----Original Message-----
From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 1:50 PM
To: Tomcat Users List
Subject: RE: Deploying/Undeploying application using the manager webapp
Well, commons-logging is the cause of a lot of headaches and it is much better to use Log4j directly, but since Struts is sort of married to it, you'll have to deal with it. Anyway, that is where I'd look first. Tomcat also uses commons-logging heavily and commons-logging uses classloader tricks in various places. I can see where Tomcat might think that it it needs to hold onto commons-logging resources and get the ones loaded from your WEB-INF/lib mixed up with other ones in the classpath. You just never know.
What I'd do is attempt to remove the app via the manager app. After this, go and try to manually delete parts of the webapp directory structure to see exactly which files are locked. Once you do this, you will have narrowed down which libraries are holding onto resources long after they should be. You may have to call some shutdown method(s) using a servlet context listener or something.
Jake
At 01:39 PM 6/3/2003 +1000, you wrote:
Jacob,
Thanks for the reply. I may need some clarification as I'm a bit of a
newbie
when it comes to Tomcat deployment.
we are using struts and all the struts packages we use are in our app lib directory. I read somewhere that this is the preferred location. Is this wrong?
we're not using log4j in the app itself, but rather commons-logging, jdom and sitemesh. Got your message regarding commons-loggins, do you know if it applies to these jars as well?
Cheers,
Bonny
-----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 1:18 PM To: Tomcat Users List Subject: Re: Deploying/Undeploying application using the manager webapp
Which jars are locked? There was an issue like this with log4j. I can't remember the exact reason, but it was fixed with the 1.2.8 release. Anything that grabs hangs onto resources is going to be an issue. In the case of Struts, I'd make sure you don't have commons-logging stuff in WEB-INF/lib. Put it in common/lib if it isn't already there.
Jake
At 11:05 AM 6/3/2003 +1000, you wrote:
All,
I have some problems using the undeploy/deploy manager web app commands to perform their tasks. Basically it seems that resources are still left open, in particular jar files in my app's WEB-INF/lib directory are kept locked and so are not removed from the file system upon calls to remove/undeploy using ant tasks.
I've searched through the archives but I see no reference to this
problem.
I'm obviously looking in the wrong place...
This is a problem for me since I'm trying to automate the redeployment cycle during development. The only solution I found so far was to stop Tomcat altogether and restart it, which kind of defeats the purpose of using the Manager app in the first place.
My setup: Tomcat 4.1.12 running as a service on Windows XP, A web app using struts.
Any help would be appreciated.
Cheers,
Bonny CAUTION - This message may contain privileged and confidential
information
intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Siemens Ltd., ABN 98004347880, or Siemens (NZ) Limited immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Siemens Ltd., ABN 98004347880, or Siemens (NZ) Limited immediately.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Siemens Ltd., ABN 98004347880, or Siemens (NZ) Limited immediately.
--------------------------------------------------------------------- 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]
