tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Fwd: log4j.jar locked by Tomcat even after remove/undeploy ....
Date Thu, 10 Oct 2002 03:54:47 GMT

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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message