I don't know, perhaps my solution is too simplistic or too low-tech, but for a webapp, I simply have a URL that I ping when I change the log4j config file. Since the config file doesn't change automatically, it's pretty trivial to hit the URL right after I change the file. I agree, it's not fully automatic, but it certainly does avoid all the rest of the headache with timers and threads.
Another option which I've considered using is to put a test at login time (don't care who the user is) to see if its time to re-check and possibly re-load the config file. The last update time could be held statically in the class which handles the reloading, and synchronization used to avoid duplicate updates. This is basically a "polling" version of WatchAndConfig.
BTW, you could do this anywhere, but login seemed like a decent compromise between checking it constantly for each doPost, and putting it somewhere more obscure that might not get run regularly. So if no one is logged into my webapp, I probably don't care what level I'm logging at, and if I do care for some reason, I can always login myself!
Just a thought ...
--- regards --- Larry
At 12:31 PM 11/11/03, you wrote:
I don't think addShutdownHook() is enough for a J2EE deployment if you are relying on static initialization of the thread. Static initialization occurs upon application deployment, but the shutdown hook would only run when the server is stopped, not when the application is undeployed. Consequently, the application would probably fail to undeploy properly, which could eventually cause the app server to run out of memory.
AFAIK, in J2EE 1.3 there is no application level startup or shutdown hook. Maybe something can be done with JMX?
Ken
> -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2003 1:50 PM > To: Log4J Users List > Subject: RE: automatic reload > > > > Howdy, > A decent place to stop and start such threads in a servlet container > would be the ServletContextListener. > > There is no static destructor, but you have Runtime#addShutdownHook > which is suitable for this purpose as well. Create a little Runnable > class with a reference to the Watchdog thread, add your Runnable as a > shutdown hook, the JVM will run it (once) on shutdown, and > your Runnable > should interrupt the log4j Watchdog thread. This approach is good > outside servlet containers as well. > > Yoav Shapira > Millennium ChemInformatics > > > >-----Original Message----- > >From: Tom Eugelink [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, November 11, 2003 1:45 PM > >To: Log4J Users List > >Subject: Re: automatic reload > > > >Hey Mark, > > > >Well, I could always try to make time (time suddenly is a rare > commodity > >once you furthered yourself in the human genepool, at least for the > next > >6 years or so). > > > >What I see as a problem is not so much the automatic starting of a > >thread, but when to stop it. In a stand alone application this is not > >such a problem, but in a container, where you have a separate > >configuration for each context (webapp0, I can't imagine > where to hook > >that in, in a generic fashion. Starting could be done in the static > >constructor of a class, which is loaded by the classloader of the > >context, but AFAIK there is no static destructor. > > > >How does the plugin logic start and stop plugins? > > > >Tom > > > > > > > >Mark Womack wrote: > > > >> Tom, > >> > >> In v1.3 Watchdogs will be a subclass of Plugin. Plugins are new to > v1.3 > >and > >> configurable from (at least xml) configuration files. So, > you'll be > able > >to > >> define watchdogs in the configuration files. Plugins have > some code > to > >not > >> stop/recreate running plugins during reconfiguration, so eventually > if a > >> watchdog is watching the configuration file that defines > it, it will > be > >> maintained across reconfigurations, etc. Still working out some of > those > >> details. Actually the Watchdog code I released way-back-when still > needs > >to > >> be checked into cvs and worked into the plugin infrastructure. > >> > >> If you have any comments, ideas, or time to review (once I get it > checked > >> in) I'd love to hear them. > >> > >> thanks, > >> -Mark > >> > >> > >>>-----Original Message----- > >>>From: Tom Eugelink [mailto:[EMAIL PROTECTED] > >>>Sent: Tuesday, November 11, 2003 6:06 AM > >>>To: Log4J Users List > >>>Subject: Re: automatic reload > >>> > >>> > >>>I see (took a look at the sources that were included in the > >>>older mail). > >>> > >>>Basically he has rewritten the "AndWatch" part, expanding it into a > >>>semi-framework, and adding a method to stop the thread > >>>("stopWatching"). > >>> > >>>Basically one could write a servlet that starts a watchdog > >>>upon load and > >>>stops it upon finalize. It still isn't done totally external of the > >>>application via configuration, but I can see how that can be > >>>a problem. > >>> > >>>I'll ponder a bit more. Thank you! > >>> > >>>Tom > >>> > >>> > >>> > >>>Jacob Kjome wrote: > >>> > >>> > >>>>look at configureAndWatch() in the configurators. > >>>> > >>>>However, I wouldn't use this in a container as the thread > >>> > >>>will run until > >>> > >>>>the JVM is shut down. There is no manual way to stop it. > >>>> > >>>>Look for Mark Womack's watchdogs in the next version of > Log4j for a > >>>>better solution. Here's an old message with some actual > >>> > >>>code showing > >>> > >>>>how it works. Check the latest CVS, though, as things have > >>> > >>>probably > >>> > >>>>changed... > >>>>http://marc.theaimsgroup.com/?l=log4j-user&m=101656353725142&w=2 > >>>> > >>>>Jake > >>>> > >>>>At 01:52 PM 11/9/2003 +0100, you wrote: > >>>> > >>>> > >>>>>I know there is a parameter which can be used to specifiy > >>> > >>>that log4j > >>> > >>>>>must reload a configuration file (checking every so often). But I > >>>>>prefer autoconfiguration. AFAIK it is not possible to set > >>> > >>>autoreload > >>> > >>>>>from a configuration file, correct? > >>>>> > >>>>>Tom > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>>----------------------------------------------------------- > ---------- > >>> > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: > [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>>----------------------------------------------------------- > ---------- > >>> > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: > [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >>>----------------------------------------------------------- > ---------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > This e-mail, including any attachments, is a confidential > business communication, and may contain information that is > confidential, proprietary and/or privileged. This e-mail is > intended only for the individual(s) to whom it is addressed, > and may not be saved, copied, printed, disclosed or used by > anyone else. If you are not the(an) intended recipient, > please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
