You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Mark Womack <mw...@bevocal.com> on 2002/09/24 22:52:44 UTC

RE: Re[4]: log4j.jar locked by Tomcat even after remove/undeploy ....

Maybe this has already been discussed...but what does your log4j init
servlet look like?  Can you post the code?

-Mark

> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Tuesday, September 24, 2002 1:51 PM
> To: Log4J Users List
> Subject: Re[4]: log4j.jar locked by Tomcat even after
> remove/undeploy....
> 
> 
> Hello Ceki,
> 
> I'm using log4j-1.2.6.  I just tested the app after commenting out the
> <load-on-startup> line for the log4j-init servlet in the 
> web.xml.  log4j.jar is *not* locked
> after shutting down the application.  I don't have to shut down the
> server to release the resource in this case.
> 
> Jake
> 
> Tuesday, September 24, 2002, 2:23:56 PM, you wrote:
> 
> 
> CG> Which version of log4j is this? Tomcat? Can you see what 
> happens if log4j 
> CG> is not configured at all?
> 
> CG> At 14:05 24.09.2002 -0500, you wrote:
> >>Hello Jacob,
> >>
> >>After testing with and without using configureAndWatch(), I am sorry
> >>to say that I get the same behavior.  The lo4j.jar is still locked
> >>until I shut down the whole Tomcat server.  Shutting down 
> the current
> >>webapp releases *all* resource except log4j.jar.
> >>
> >>Any suggestions?
> >>
> >>Jake
> >>
> >>Tuesday, September 24, 2002, 10:21:42 AM, you wrote:
> >>
> >>
> >>JK> BTW, the attachment is a .zip file.  Just save it as 
> whatever.zip and
> >>JK> you should be able to open it.  Don't know why the extension got
> >>JK> mangled so bad?
> >>
> >>JK> BTW, would using configureAndWatch() be the problem?  
> I'll test in a
> >>JK> second.  We use that by default.  I'll post back with 
> my results to
> >>JK> running the app and *not* using configureAndWatch().
> >>
> >>JK> Jake
> >>
> >>JK> Tuesday, September 24, 2002, 8:34:09 AM, you wrote:
> >>
> >>JK>> Hi Ceki,
> >>
> >>JK>> Nope, we aren't using anything fancy like NTEventLogAppender.
> >>
> >>JK>> I'll attaching everything that we use in our webapp 
> related to log4j so
> >>JK>> that you can see everything that is going on.  Note, 
> we are using 
> >>log4j-1.2.6.
> >>
> >>JK>> thanks,
> >>
> >>JK>> Jake
> >>
> >>
> >>JK>> At 08:29 AM 9/24/2002 +0200, you wrote:
> >>
> >> >>>Are you using NTEventLogAppender?
> >> >>>
> >> >>>At 20:31 23.09.2002 -0500, you wrote:
> >> >>>
> >> >>>>Can someone in-the-know please comment on this?
> >> >>>>
> >> >>>>This is my last major build problem.  It really gets 
> in the way because
> >> >>>>if I test my app in Tomcat (haven't tried other 
> servers) and then 
> >> need to
> >> >>>>shut the app down and rebuild after making some 
> changes, I can't 
> >> clean up
> >> >>>>the build because log4j.jar is locked and can't be 
> deleted (I copy all
> >> >>>>files to a "build" directory and just delete the build 
> directory when I
> >> >>>>want to do a clean build).
> >> >>>>
> >> >>>>Log4j.jar is the only file that is ever locked so 
> there must be 
> >> something
> >> >>>>unique about and something that isn't getting stopped. 
>  Read below for
> >> >>>>more explanation.....
> >> >>>>
> >> >>>>Jake
> >> >>>>
> >> >>>>At 05:26 AM 9/21/2002 -0500, you wrote:
> >> >>>>
> >> >>>>>This issue has been brought up before with no response....
> >> >>>>>
> >> >>>>>I use Tomcat-4.1.11 and the manager app to install/remove |
> >> >>>>>deploy/undeploy | start/stop my webapp which contains 
> >> log4j-1.2.6.jar in
> >> >>>>>WEB-INF/lib.  What I'd like to be able to do is 
> uninstall or undeploy
> >> >>>>>the webapp and run a clean build.  However, whenever 
> I do this the 
> >> build
> >> >>>>>fails because it cannot delete the log4j jar file.  I've used
> >> >>>>>LogManager.shutdown() in a ServletContextListener 
> which will get run
> >> >>>>>upon being notified that the app is shutting down.  
> This does not
> >> >>>>>help....well, it does help in unlocking the log file 
> that gets written
> >> >>>>>while the webapp is running which gets written using 
> a FileAppender, 
> >> but
> >> >>>>>it doesn't unlock the actual log4j jar file.   The 
> only way it gets
> >> >>>>>unlocked is by performing a *full* shutdown of Tomcat.
> >> >>>>>
> >> >>>>>Shutting down Tomcat is unacceptable because I don't 
> want to affect the
> >> >>>>>other apps running on the server.  I have worked 
> around it by not doing
> >> >>>>>a full clean build and just doing a normal build 
> which replaces files
> >> >>>>>that have changed.  However, this is very 
> inconvenient because if I
> >> >>>>>remove files or change the names of files, I need to 
> do a clean 
> >> build to
> >> >>>>>get rid of the old ones.  Plus, I'd like to be able 
> to zip up the build
> >> >>>>>directory structure or just remove the entire build 
> from that location
> >> >>>>>without having to shut down Tomcat.  In both cases I 
> get errors because
> >> >>>>>the log4j jar file is locked.
> >> >>>>>
> >> >>>>>Now, I would look to Tomcat first and blame it for 
> failing to release
> >> >>>>>resources.  However, I don't have this problem with 
> *any* other file,
> >> >>>>>jar or otherwise.  So, it seems that Log4j must be 
> doing something
> >> >>>>>peculiar.  However, I have yet to figure out what that is.
> >> >>>>>
> >> >>>>>Can anyone help me figure out what this problem and 
> its solution might
> >> >>>>>be?  Do we need to add a new static method called
> >> >>>>>LogManager.reallyShutdownNoIReallyMeanItJustShutdownAlready()?
> >> >>>>>
> >> >>>>>Thanks,
> >> >>>>>
> >> >>>>>Jake
> >> >>>>>
> >> >>>>>
> >> >>>>>--
> >> >>>>>To unsubscribe, 
> >> e-mail:   <ma...@jakarta.apache.org>
> >> >>>>>For additional commands, e-mail: 
> >> <ma...@jakarta.apache.org>
> >> >>>
> >> >>>--
> >> >>>Ceki
> >> >>>
> >> >>>TCP implementations will follow a general principle of 
> robustness: be
> >> >>>conservative in what you do, be liberal in what you accept from
> >> >>>others. -- Jon Postel, RFC 793
> >> >>>
> >> >>>
> >> >>>
> >> >>>--
> >> >>>To unsubscribe, 
> >> e-mail:   <ma...@jakarta.apache.org>
> >> >>>For additional commands, e-mail: 
> >> <ma...@jakarta.apache.org>
> >>
> >>
> >>
> >>
> >>
> >>
> >>--
> >>Best regards,
> >>  Jacob                            mailto:hoju@visi.com
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
>>For additional commands, e-mail:
<ma...@jakarta.apache.org>

CG> --
CG> Ceki

CG> TCP implementations will follow a general principle of robustness: be
CG> conservative in what you do, be liberal in what you accept from
CG> others. -- Jon Postel, RFC 793



CG> --
CG> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
CG> For additional commands, e-mail:
<ma...@jakarta.apache.org>



-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re[6]: log4j.jar locked by Tomcat even after remove/undeploy ....

Posted by Jacob Kjome <ho...@visi.com>.
Hello Mark,

See this message:
http://marc.theaimsgroup.com/?l=log4j-user&m=103287412303294&w=2

At the bottom, there is a link to the zip file I posted of all code
that has to do with setting up log4j in our app...including
log4jinit.java.

http://marc.theaimsgroup.com/?l=log4j-user&m=103287412303294&q=p6

Jake

Tuesday, September 24, 2002, 3:52:44 PM, you wrote:

MW> Maybe this has already been discussed...but what does your log4j init
MW> servlet look like?  Can you post the code?

MW> -Mark

>> -----Original Message-----
>> From: Jacob Kjome [mailto:hoju@visi.com]
>> Sent: Tuesday, September 24, 2002 1:51 PM
>> To: Log4J Users List
>> Subject: Re[4]: log4j.jar locked by Tomcat even after
>> remove/undeploy....
>> 
>> 
>> Hello Ceki,
>> 
>> I'm using log4j-1.2.6.  I just tested the app after commenting out the
>> <load-on-startup> line for the log4j-init servlet in the 
>> web.xml.  log4j.jar is *not* locked
>> after shutting down the application.  I don't have to shut down the
>> server to release the resource in this case.
>> 
>> Jake
>> 
>> Tuesday, September 24, 2002, 2:23:56 PM, you wrote:
>> 
>> 
>> CG> Which version of log4j is this? Tomcat? Can you see what 
>> happens if log4j 
>> CG> is not configured at all?
>> 
>> CG> At 14:05 24.09.2002 -0500, you wrote:
>> >>Hello Jacob,
>> >>
>> >>After testing with and without using configureAndWatch(), I am sorry
>> >>to say that I get the same behavior.  The lo4j.jar is still locked
>> >>until I shut down the whole Tomcat server.  Shutting down 
>> the current
>> >>webapp releases *all* resource except log4j.jar.
>> >>
>> >>Any suggestions?
>> >>
>> >>Jake
>> >>
>> >>Tuesday, September 24, 2002, 10:21:42 AM, you wrote:
>> >>
>> >>
>> >>JK> BTW, the attachment is a .zip file.  Just save it as 
>> whatever.zip and
>> >>JK> you should be able to open it.  Don't know why the extension got
>> >>JK> mangled so bad?
>> >>
>> >>JK> BTW, would using configureAndWatch() be the problem?  
>> I'll test in a
>> >>JK> second.  We use that by default.  I'll post back with 
>> my results to
>> >>JK> running the app and *not* using configureAndWatch().
>> >>
>> >>JK> Jake
>> >>
>> >>JK> Tuesday, September 24, 2002, 8:34:09 AM, you wrote:
>> >>
>> >>JK>> Hi Ceki,
>> >>
>> >>JK>> Nope, we aren't using anything fancy like NTEventLogAppender.
>> >>
>> >>JK>> I'll attaching everything that we use in our webapp 
>> related to log4j so
>> >>JK>> that you can see everything that is going on.  Note, 
>> we are using 
>> >>log4j-1.2.6.
>> >>
>> >>JK>> thanks,
>> >>
>> >>JK>> Jake
>> >>
>> >>
>> >>JK>> At 08:29 AM 9/24/2002 +0200, you wrote:
>> >>
>> >> >>>Are you using NTEventLogAppender?
>> >> >>>
>> >> >>>At 20:31 23.09.2002 -0500, you wrote:
>> >> >>>
>> >> >>>>Can someone in-the-know please comment on this?
>> >> >>>>
>> >> >>>>This is my last major build problem.  It really gets 
>> in the way because
>> >> >>>>if I test my app in Tomcat (haven't tried other 
>> servers) and then 
>> >> need to
>> >> >>>>shut the app down and rebuild after making some 
>> changes, I can't 
>> >> clean up
>> >> >>>>the build because log4j.jar is locked and can't be 
>> deleted (I copy all
>> >> >>>>files to a "build" directory and just delete the build 
>> directory when I
>> >> >>>>want to do a clean build).
>> >> >>>>
>> >> >>>>Log4j.jar is the only file that is ever locked so 
>> there must be 
>> >> something
>> >> >>>>unique about and something that isn't getting stopped. 
>>  Read below for
>> >> >>>>more explanation.....
>> >> >>>>
>> >> >>>>Jake
>> >> >>>>
>> >> >>>>At 05:26 AM 9/21/2002 -0500, you wrote:
>> >> >>>>
>> >> >>>>>This issue has been brought up before with no response....
>> >> >>>>>
>> >> >>>>>I use Tomcat-4.1.11 and the manager app to install/remove |
>> >> >>>>>deploy/undeploy | start/stop my webapp which contains 
>> >> log4j-1.2.6.jar in
>> >> >>>>>WEB-INF/lib.  What I'd like to be able to do is 
>> uninstall or undeploy
>> >> >>>>>the webapp and run a clean build.  However, whenever 
>> I do this the 
>> >> build
>> >> >>>>>fails because it cannot delete the log4j jar file.  I've used
>> >> >>>>>LogManager.shutdown() in a ServletContextListener 
>> which will get run
>> >> >>>>>upon being notified that the app is shutting down.  
>> This does not
>> >> >>>>>help....well, it does help in unlocking the log file 
>> that gets written
>> >> >>>>>while the webapp is running which gets written using 
>> a FileAppender, 
>> >> but
>> >> >>>>>it doesn't unlock the actual log4j jar file.   The 
>> only way it gets
>> >> >>>>>unlocked is by performing a *full* shutdown of Tomcat.
>> >> >>>>>
>> >> >>>>>Shutting down Tomcat is unacceptable because I don't 
>> want to affect the
>> >> >>>>>other apps running on the server.  I have worked 
>> around it by not doing
>> >> >>>>>a full clean build and just doing a normal build 
>> which replaces files
>> >> >>>>>that have changed.  However, this is very 
>> inconvenient because if I
>> >> >>>>>remove files or change the names of files, I need to 
>> do a clean 
>> >> build to
>> >> >>>>>get rid of the old ones.  Plus, I'd like to be able 
>> to zip up the build
>> >> >>>>>directory structure or just remove the entire build 
>> from that location
>> >> >>>>>without having to shut down Tomcat.  In both cases I 
>> get errors because
>> >> >>>>>the log4j jar file is locked.
>> >> >>>>>
>> >> >>>>>Now, I would look to Tomcat first and blame it for 
>> failing to release
>> >> >>>>>resources.  However, I don't have this problem with 
>> *any* other file,
>> >> >>>>>jar or otherwise.  So, it seems that Log4j must be 
>> doing something
>> >> >>>>>peculiar.  However, I have yet to figure out what that is.
>> >> >>>>>
>> >> >>>>>Can anyone help me figure out what this problem and 
>> its solution might
>> >> >>>>>be?  Do we need to add a new static method called
>> >> >>>>>LogManager.reallyShutdownNoIReallyMeanItJustShutdownAlready()?
>> >> >>>>>
>> >> >>>>>Thanks,
>> >> >>>>>
>> >> >>>>>Jake
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>--
>> >> >>>>>To unsubscribe, 
>> >> e-mail:   <ma...@jakarta.apache.org>
>> >> >>>>>For additional commands, e-mail: 
>> >> <ma...@jakarta.apache.org>
>> >> >>>
>> >> >>>--
>> >> >>>Ceki
>> >> >>>
>> >> >>>TCP implementations will follow a general principle of 
>> robustness: be
>> >> >>>conservative in what you do, be liberal in what you accept from
>> >> >>>others. -- Jon Postel, RFC 793
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>--
>> >> >>>To unsubscribe, 
>> >> e-mail:   <ma...@jakarta.apache.org>
>> >> >>>For additional commands, e-mail: 
>> >> <ma...@jakarta.apache.org>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>--
>> >>Best regards,
>> >>  Jacob                            mailto:hoju@visi.com
>> >>
>> >>
>> >>--
>> >>To unsubscribe, e-mail:   
MW> <ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
MW> <ma...@jakarta.apache.org>

CG>> --
CG>> Ceki

CG>> TCP implementations will follow a general principle of robustness: be
CG>> conservative in what you do, be liberal in what you accept from
CG>> others. -- Jon Postel, RFC 793



CG>> --
CG>> To unsubscribe, e-mail:
MW> <ma...@jakarta.apache.org>
CG>> For additional commands, e-mail:
MW> <ma...@jakarta.apache.org>






-- 
Best regards,
 Jacob                            mailto:hoju@visi.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>