logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <mwom...@apache.org>
Subject RE: FW: log4j.jar locked by Tomcat even after remove/undeploy ....
Date Mon, 07 Oct 2002 04:39:08 GMT
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:
>
> <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: 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:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>


Mime
View raw message