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:[EMAIL PROTECTED]] > 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: [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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
