tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cox, Charlie" <c...@cincom.com>
Subject RE: log4j.jar locked by Tomcat even after remove/undeploy ....
Date Thu, 10 Oct 2002 18:22:09 GMT
the jvm has the library loaded, not tomcat. It will not be released until
the jvm(incuding tomcat) is stopped.

Charlie

> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Wednesday, October 09, 2002 11:55 PM
> To: Tomcat Users List
> Subject: Fwd: log4j.jar locked by Tomcat even after 
> remove/undeploy ....
> 
> 
> 
> Hmm... This got no response on the tomcat-dev list.  Does 
> anyone in the 
> Tomcat-use list have any clue as to why the log4j jar is 
> getting locked 
> even after a Tomcat manager stop/remove/undeploy?
> 
> Jake
> 
> 
> >Date: Tue, 08 Oct 2002 00:14:40 -0500
> >To: tomcat-dev@jakarta.apache.org
> >From: Jacob Kjome <hoju@visi.com>
> >Subject: log4j.jar locked by Tomcat even after  remove/undeploy ....
> >
> >
> >Hi Tomcat developers,
> >
> >Below is a discussion that has been ongoing on the log4j-dev 
> list.  We are 
> >trying to figure out why the log4j jar file is locked after 
> a webapp is 
> >removed from Tomcat using the Tomcat manager app.  
> Basically, all jar 
> >resources in a webapp are let go after a manager "remove" 
> except for the 
> >log4j jar (within WEB-INF/lib).  In order to remove the lock 
> on the jar, 
> >Tomcat has to be shut down completely, not just have the webapp 
> >removed.  We had thought we had found the reason for it (static 
> >initializers) but that didn't turn out to be reproducible.  
> At this point, 
> >we are a bit perplexed.
> >
> >Can any Tomcat developers tell us if there are any 
> classloading issues 
> >with Tomcat that might cause Tomcat to hold onto a jar file in the 
> >WEB-INF/lib directory after the app has been removed via the manager 
> >app?  Could it be commons-logging that is holding onto it?  
> Any help would 
> >be appreciated.
> >
> >BTW, could cross-post responses to log4j-dev@jakarta.apache.org?
> >
> >thanks,
> >
> >Jake
> >
> >
> >>Date: Mon, 07 Oct 2002 07:12:30 -0500
> >>To: "Log4J Developers List" <log4j-dev@jakarta.apache.org>
> >>From: Jacob Kjome <hoju@visi.com>
> >>Subject: RE: FW: log4j.jar locked by Tomcat even after  
> remove/undeploy
> >>
> >>
> >>I'll pose this question to the tomcat-user and/or tomcat-dev list 
> >>sometime today.  Maybe they can help us out on this.
> >>
> >>Jake
> >>
> >>At 09:39 PM 10/6/2002 -0700, you wrote:
> >>>I swear, I reproduced this multiple times before I posted 
> my earlier
> >>>message.  When I just tried it, the problem did not 
> happen.  Ack, this is
> >>>frustrating!
> >>>
> >>>What else can we use to attack this problem?  Is there 
> some way to tell what
> >>>is active in the JVM that is preventing the jar from being 
> unloaded?
> >>>
> >>>-Mark
> >>>
> >>> > -----Original Message-----
> >>> > From: Jacob Kjome [mailto:hoju@visi.com]
> >>> > Sent: Saturday, October 05, 2002 6:46 PM
> >>> > To: log4j-dev@jakarta.apache.org
> >>> > Subject: Re: FW: log4j.jar locked by Tomcat even after 
> remove/undeploy
> >>> > ....
> >>> >
> >>> >
> >>> >
> >>> > Hi Mark,
> >>> >
> >>> > I am now subscribed to the log4j-dev list.
> >>> >
> >>> > I tested all the scenarios that you described, but I never found
> >>> > static_test.jar to be locked except for when the 
> application is installed
> >>> > (as expected).  When I remove the app, the only thing 
> that is locked is
> >>> > log4j-1.2.6.jar.  I can delete everything other than that.
> >>> >
> >>> > It is really curious that it locks for you and doesn't for me???
> >>> > The thing
> >>> > is in Barracuda, the open source Presentation 
> Framework, where the
> >>> > Log4jInit and Log4jApplicationWatch come from, there 
> are a number
> >>> > of places
> >>> > that use static initializers and I find no locking 
> issues with the
> >>> > Barracuda libraries.
> >>> >
> >>> > Has anyone else reproduced Mark's results?
> >>> >
> >>> >
> >>> >
> >>> > BTW, mark, when you use Log4jInit, you can just have 
> the param for the
> >>> > FileApender look something like this:
> >>> >
> >>> > <param name="File" value="${barracuda.log.home}/main.log" />
> >>> >
> >>> > Basically, Log4jInit gerates a system variable based on 
> the name of the
> >>> > webapp context.  Here is how it works:
> >>> >
> >>> > [name of webapp context].log.home
> >>> >
> >>> > So, a webapp at:
> >>> >
> >>> > http://localhost:8080/barracuda/
> >>> >
> >>> > would create a system variable named "barracuda.log.home"
> >>> >
> >>> > A webapp at:
> >>> >
> >>> > http://localhost:8080/myapp/
> >>> >
> >>> > would create a system variable named "myapp.log.home"
> >>> >
> >>> > Just look for the file "main.log" in WEB-INF/logs 
> directory of you
> >>> > webapp.  If the "logs" directory doesn't exist, it will be
> >>> > created.  So, it
> >>> > doesn't matter where your webapp is deployed from as 
> long as it isn't
> >>> > deployed directly from a .war file, you will never have 
> to bother setting
> >>> > the path.  It will be found automatically.
> >>> >
> >>> > If you want to override the path where the log file 
> gets written,
> >>> > just set
> >>> > the "log4j-log-home" parameter for the Log4jInit 
> servlet in the web.xml
> >>> > such as:
> >>> >
> >>> > <param-name>log4j-log-home</param-name>
> >>> > <param-value>D:\my\logging\path</param-value>
> >>> >
> >>> > Nice and flexible, heh?
> >>> >
> >>> > Jake
> >>> >
> >>> >
> >>> > At 10:52 AM 10/4/2002 -0700, you wrote:
> >>> > >The discussion has moved to the log4j-dev email list, 
> but I don't 
> >>> know if
> >>> > >you are currently subscribed to that list, so I am 
> forwarding it to you.
> >>> > >Please let me know what you find.
> >>> > >
> >>> > >-Mark
> >>> > >
> >>> > >-----Original Message-----
> >>> > >From: mwomack@apache.org [mailto:mwomack@apache.org]
> >>> > >Sent: Thursday, October 03, 2002 11:18 PM
> >>> > >To: log4j-dev@jakarta.apache.org
> >>> > >Subject: RE: log4j.jar locked by Tomcat even after 
> remove/undeploy ....
> >>> > >
> >>> > >
> >>> > >Ceki & Jake,
> >>> > >
> >>> > >I have done some more tests, and I believe very strongly that
> >>> > the problem is
> >>> > >in Tomcat.  I have enclosed my entire webapp (I am 
> still using the one I
> >>> > >made last night, with some modifications, and you will 
> need to add the
> >>> > >log4j-1.2.6.jar to your deployment; I did not include it in the
> >>> > enclosed zip
> >>> > >file).
> >>> > >
> >>> > >Here is what I do, you tell me what you think:
> >>> > >
> >>> > >1) I created 2 new classes, org.womacknet.StaticTest and
> >>> > >org.womacknet.NonStaticTest.  StaticTest has a static 
> initializer 
> >>> defined
> >>> > >and 2 static members.  NonStaticTest does not have a static
> >>> > intitializer and
> >>> > >only an instance member.  I compiled these files and put them
> >>> > into their own
> >>> > >static_test.jar, which I placed into the WEB-INF/lib.
> >>> > >
> >>> > >2) I created 2 jsp pages, static_test.jsp and
> >>> > non_static_test.jsp.  As you
> >>> > >can guess, each references the StaticTest or 
> NonStaticTest classes
> >>> > >respectively.  The classes are only referenced/used by 
> these jsp's 
> >>> and no
> >>> > >where else.
> >>> > >
> >>> > >3) I deployed the webapp outside of the Tomcat 
> directory structure, and
> >>> > >initially without the jsp's.  I did the following 
> command to deploy 
> >>> it in
> >>> > >Tomcat:
> >>> > >
> >>> > 
> >http://localhost:8080/manager/install?path=/barracuda&war=file://
> >>> > /D:/develop
> >>> > >ment/barracuda/barracuda-webapp
> >>> > >
> >>> > >All is happy.
> >>> > >
> >>> > >4) Just to check, while it is deployed I tried to move 
> both the 
> >>> log4j and
> >>> > >static_test jars.  Both report that they are locked 
> and cannot be moved,
> >>> > >expected behavior.
> >>> > >
> >>> > >5) I then undeploy the web app with the following command:
> >>> > >
> >>> > 
> >http://localhost:8080/manager/remove?path=/barracuda&war=file:///
> >>>D:/developm
> >>> >ent/barracuda/barracuda-webapp
> >>> >
> >>> >All is happy.
> >>> >
> >>> >6) I go back to move the jars.  The static_test.jar can 
> be moved, but not
> >>> >the log4j jar.  This is the reported problem.
> >>> >
> >>> >7) Shutdown Tomcat, startup tomcat, deploy the webapp.
> >>> >
> >>> >8) Copy the non_static_test.jsp to the top level of the 
> webapp, and access
> >>> >it:
> >>> >
> >>> >http://localhost:8080/barracuda/non_static_test.jsp
> >>> >
> >>> >All is happy.
> >>> >
> >>> >9) Undeploy the web app, try to move the jars.  Again, 
> static_test.jar 
> >>> will
> >>> >move, but log4j jar will not.
> >>> >
> >>> >10) Shutdown Tomcat, startup tomcat, deploy the webapp.
> >>> >
> >>> >11) Copy the static_test.jsp to the top level of the webapp, and 
> >>> access it:
> >>> >
> >>> >http://localhost:8080/barracuda/static_test.jsp
> >>> >
> >>> >Access the non_static_test.jsp too, if you want.  All is happy.
> >>> >
> >>> >12) Undeploy the web app, try to move the jars.  Now neither the
> >>>static_test
> >>> >jar nor the log4j jar will move.
> >>> >
> >>> >Please see if you can replicate this behavior locally.  
> I believe this
> >>> >proves there is an issue with the Tomcat web application 
> class loader (?)
> >>> >regarding classes that either have static intializers 
> and/or static 
> >>> members
> >>> >(which log4j does have).  I can replicate the same 
> locked jar behavior 
> >>> with
> >>> >a non-log4j related jar, and the behavior only occurs 
> when the class with
> >>> >the static initializer/members is actually loaded/used.  
> If it is not
> >>> >loaded/used, then the locked jar behavior does not 
> occur.  As such, and
> >>> >assuming you can replicate the behavior I am seeing, I 
> do not believe this
> >>> >is a log4j problem.
> >>> >
> >>> >Please let me know what you find.  If you find the same 
> behavior, please
> >>> >report the problem to the Tomcat development team so 
> they comment and/or
> >>> >fix.
> >>> >
> >>> >thanks!
> >>> >-Mark
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail:   
<mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>>>For additional commands, e-mail:
<mailto:log4j-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message