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