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 Ceki Gülcü <ce...@qos.ch> on 2002/09/24 21:23:56 UTC
Re[3]: log4j.jar locked by Tomcat even after
remove/undeploy....
Which version of log4j is this? Tomcat? Can you see what happens if log4j
is not configured at all?
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>
--
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>
Re[4]: log4j.jar locked by Tomcat even after remove/undeploy....
Posted by Jacob Kjome <ho...@visi.com>.
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>