logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Hudak <CHu...@arrowheadgrp.com>
Subject RE: automatic reload
Date Tue, 11 Nov 2003 23:56:44 GMT
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:mwomack@bevocal.com]
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:lyoung@dalmatian.com]
> 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:Yoav.Shapira@mpi.com]
> > > 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:tbee@tbee.org]
> > > >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:tbee@tbee.org]
> > > >>>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: 
> log4j-user-unsubscribe@jakarta.apache.org
> > > >>>>>For additional commands, e-mail:
> > > log4j-user-help@jakarta.apache.org
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>-----------------------------------------------------------
> > > ----------
> > > >>>
> > > >>>>To unsubscribe, e-mail: 
> log4j-user-unsubscribe@jakarta.apache.org
> > > >>>>For additional commands, e-mail:
> > > log4j-user-help@jakarta.apache.org
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>-----------------------------------------------------------
> > > ----------
> > > >>>To unsubscribe, e-mail: 
> log4j-user-unsubscribe@jakarta.apache.org
> > > >>>For additional commands, e-mail: 
> log4j-user-help@jakarta.apache.org
> > > >>>
> > > >>
> > > >>
> > > >>
> > > 
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: 
> log4j-user-unsubscribe@jakarta.apache.org
> > > >> For additional commands, e-mail: 
> log4j-user-help@jakarta.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail: 
> log4j-user-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> > > 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: log4j-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> log4j-user-help@jakarta.apache.org
> > >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> 
> --------------------------
> Larry Young
> The Dalmatian Group
> www.dalmatian.com 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org



Mime
View raw message