tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re[2]: log4j.jar locked by Tomcat even after remove/undeploy ....
Date Thu, 10 Oct 2002 18:34:42 GMT
Hello Charlie,

Well, when I stop/uninstall/undeploy the app from Tomcat using the
manager app, the *only* file that is locked is the log4j jar.  *All*
other libraries including jar files are released.  The question is,
why is only log4j getting locked up.  If I were to take your statement
at face value, I would expect *all* jars to be locked until the server
is shut down.  However, they aren't.  Only log4j has this problem.

I am beginning to suspect that it has something to do with the
commons-logging that Tomcat uses.

Any other ideas?

Jake

Thursday, October 10, 2002, 1:22:09 PM, you wrote:

CC> the jvm has the library loaded, not tomcat. It will not be released until
CC> the jvm(incuding tomcat) is stopped.

CC> 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:   
CC> <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
>>>>For additional commands, e-mail:
CC> <mailto:log4j-dev-help@jakarta.apache.org>

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



-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
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