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