I created one of these for our application. It also handles clustered servers so if you have multiple servers using the same config, it will do a reload on all of them by hitting the main url (useful if you are behind a firewall or using a big ip box, like we are). You can also have specific files for each server and it will also handle this. When you hit this servlet, you will get a results page that shows the result of the refresh.
I've attached the file if anyone is interested. -----Original Message----- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 15:46 To: 'Log4J Users List' Subject: RE: automatic reload There is a configuration servlet in the current log4j-sandbox cvs that I have been hoping to upgrade to handle the reloading of a configuration file. I just mention it because we would like to release a set of useful, servlet/webapp related classes with the v1.3 release. -Mark > -----Original Message----- > From: Larry Young [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2003 12:08 PM > To: Log4J Users List > Subject: RE: automatic reload > > > Ken, > > 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] > --------------------------------------------------------------------- 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]
