Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 97581 invoked from network); 7 Oct 2002 04:38:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Oct 2002 04:38:47 -0000 Received: (qmail 16513 invoked by uid 97); 7 Oct 2002 04:39:39 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@jakarta.apache.org Received: (qmail 16470 invoked by uid 97); 7 Oct 2002 04:39:38 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 16456 invoked by uid 98); 7 Oct 2002 04:39:37 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: To: "Log4J Developers List" Subject: RE: FW: log4j.jar locked by Tomcat even after remove/undeploy .... Date: Sun, 6 Oct 2002 21:39:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <5.1.0.14.2.20021005202133.0300bbd8@shell.visi.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > > > 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: > > log4j-log-home > D:\my\logging\path > > 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: For additional commands, e-mail: