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