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