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: <mailto:[EMAIL PROTECTED]> >>>>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >>> >>>-- >>>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: <mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
