Here you go. It's pretty straightforward. Lemme know if you have any questions.
-----Original Message----- From: Tom Eugelink [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 21:50 To: Log4J Users List Subject: Re: automatic reload I also use a servlet to reload, but since I've gotten grip on the automatic feature of log4j, I started liking it. But it seems servlets is the way to go at this time. However my servlet isn't such a fancy one like yours, so I would be interested in the source! Tom Charles Hudak wrote: > Looks the attachment got filtered out. If anyone is interested, they can > email me for the source. Sorry, but I don't have access to the cvs > repository behind our firewall to upload it. > > -----Original Message----- > From: Charles Hudak [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 11, 2003 15:57 > To: 'Log4J Users List' > Subject: RE: automatic reload > > > 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] > > --------------------------------------------------------------------- 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]
