logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Young <lyo...@dalmatian.com>
Subject RE: automatic reload
Date Tue, 11 Nov 2003 20:08:27 GMT
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


Mime
View raw message