logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Eugelink <t...@tbee.org>
Subject Re: automatic reload
Date Wed, 12 Nov 2003 05:50:28 GMT
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:CHudak@arrowheadgrp.com]
> 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: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
> 
> 
> 
> ---------------------------------------------------------------------
> 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