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: [EMAIL PROTECTED] >From: Jacob Kjome <[EMAIL PROTECTED]> >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 [EMAIL PROTECTED]? > >thanks, > >Jake > > >>Date: Mon, 07 Oct 2002 07:12:30 -0500 >>To: "Log4J Developers List" <[EMAIL PROTECTED]> >>From: Jacob Kjome <[EMAIL PROTECTED]> >>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:[EMAIL PROTECTED]] >>> > Sent: Saturday, October 05, 2002 6:46 PM >>> > To: [EMAIL PROTECTED] >>> > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >>> > >Sent: Thursday, October 03, 2002 11:18 PM >>> > >To: [EMAIL PROTECTED] >>> > >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:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
