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