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 th
Re: automatic reload
Ah, my worries are confirmed :-)
[EMAIL PROTECTED] 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: [EM
RE: Newbie question on setting different levels
On Wed, 2003-11-12 at 13:57, [EMAIL PROTECTED] wrote: > Scott, > > Is it possible that the Jakarta libraries are reconfiguring log4j on you after your > configuration has run? I ran into this with the open source Joram JMS > implemnetation. As soon as I started using the Joram classes, some static Joram > code would reconfigure log4j and blow away my whole configuration. Can you try > running configure after calling some library methods? Mark, good thinking, I'd put some money down that something like that is happening, a similar thing happened to me. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Newbie question on setting different levels
Scott,
Is it possible that the Jakarta libraries are reconfiguring log4j on you after your
configuration has run? I ran into this with the open source Joram JMS implemnetation.
As soon as I started using the Joram classes, some static Joram code would
reconfigure log4j and blow away my whole configuration. Can you try running configure
after calling some library methods?
Good luck,
Mark
-Original Message-
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Tue 11/11/2003 9:23 PM
To: Log4J Users List
Cc:
Subject: Re: Newbie question on setting different levels
I have to admit that everything you have indicated here looks fine. At
what point does the DOMConfigurator.configure("log4j.xml") call get
made? I am assuming here that it is called _before_ the call to
getEffectiveLevel(). By default all Loggers will be INFO until a
configuration sets to otherwise.
cheers,
Paul Smith
On Wed, 2003-11-12 at 11:13, Scott Smith wrote:
> I've been reading through documentation on log4j and thought I understood
> how everything works. But there is something I'm missing.
>
> Since several of the Jakarta libraries seem to log to the root logger, I
> wanted to set up the root logger with the appenders. Then I would set the
> root logger to pass ERROR or above and my own logger to pass DEBUG or above
> (so I'd see everything from my app, but only errors from the libraries).
> Based on that, I generated the following configuration file.
>
>
> --
>
>
>
> http://jakarta.apache.org/log4j/";
> debug="true">
>
>
>
>
>
>
>"org.apache.log4j.DailyRollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
>
> When I execute:
> DOMConfigurator.configure("log4j.xml");
> Everything seems to be fine and I see the following from log4j:
>
>
> log4j: Threshold ="null".
> log4j: Retreiving an instance of org.apache.log4j.Logger.
> log4j: Setting [com.mainstreamdata.messager] additivity to [true].
> log4j: Level value for com.mainstreamdata.messager is [debug].
> log4j: com.mainstreamdata.messager level set to DEBUG
> log4j: Level value for root is [error].
> log4j: root level set to ERROR
> log4j: Class name: [org.apache.log4j.ConsoleAppender]
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p %c %m%n].
> log4j: Adding appender named [CONSOLE] to category [root].
> log4j: Class name: [org.apache.log4j.DailyRollingFileAppender]
> log4j: Setting property [file] to [./Logs/log].
> log4j: Setting property [immediateFlush] to [true].
> log4j: Setting property [append] to [true].
> log4j: Setting property [datePattern] to ['.' -MM-dd].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d %-5p %m%n].
> log4j: setFile called: ./Logs/log, true
> log4j: setFile ended
> log4j: Appender [FILE] to be rolled at midnight.
> log4j: Adding appender named [FILE] to category [root].
> ---
>
> All of which looks OK to me. Here's the problem. I don't see any of my
> DEBUG logs go to either appender. In fact, if I execute the following line
> of code:
>
> System.out.println("Effective Level for " + lggr.getName() + " is "
> + lggr.getEffectiveLevel());
>
> It says:
>
> Effective Level for com.mainstreamdata.messager is INFO
>
> I don't want INFO; I want DEBUG. If I hadn't set my logger in the config
> file to DEBUG, I would have expected it to default to ERROR (the root logger
> level). I also tried enumerating through the logger repository (off of the
> root log
Re: Newbie question on setting different levels
I have to admit that everything you have indicated here looks fine. At
what point does the DOMConfigurator.configure("log4j.xml") call get
made? I am assuming here that it is called _before_ the call to
getEffectiveLevel(). By default all Loggers will be INFO until a
configuration sets to otherwise.
cheers,
Paul Smith
On Wed, 2003-11-12 at 11:13, Scott Smith wrote:
> I've been reading through documentation on log4j and thought I understood
> how everything works. But there is something I'm missing.
>
> Since several of the Jakarta libraries seem to log to the root logger, I
> wanted to set up the root logger with the appenders. Then I would set the
> root logger to pass ERROR or above and my own logger to pass DEBUG or above
> (so I'd see everything from my app, but only errors from the libraries).
> Based on that, I generated the following configuration file.
>
>
> --
>
>
>
> http://jakarta.apache.org/log4j/";
> debug="true">
>
>
>
>
>
>
>"org.apache.log4j.DailyRollingFileAppender">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
>
> When I execute:
> DOMConfigurator.configure("log4j.xml");
> Everything seems to be fine and I see the following from log4j:
>
>
> log4j: Threshold ="null".
> log4j: Retreiving an instance of org.apache.log4j.Logger.
> log4j: Setting [com.mainstreamdata.messager] additivity to [true].
> log4j: Level value for com.mainstreamdata.messager is [debug].
> log4j: com.mainstreamdata.messager level set to DEBUG
> log4j: Level value for root is [error].
> log4j: root level set to ERROR
> log4j: Class name: [org.apache.log4j.ConsoleAppender]
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p %c %m%n].
> log4j: Adding appender named [CONSOLE] to category [root].
> log4j: Class name: [org.apache.log4j.DailyRollingFileAppender]
> log4j: Setting property [file] to [./Logs/log].
> log4j: Setting property [immediateFlush] to [true].
> log4j: Setting property [append] to [true].
> log4j: Setting property [datePattern] to ['.' -MM-dd].
> log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
> log4j: Setting property [conversionPattern] to [%d %-5p %m%n].
> log4j: setFile called: ./Logs/log, true
> log4j: setFile ended
> log4j: Appender [FILE] to be rolled at midnight.
> log4j: Adding appender named [FILE] to category [root].
> ---
>
> All of which looks OK to me. Here's the problem. I don't see any of my
> DEBUG logs go to either appender. In fact, if I execute the following line
> of code:
>
> System.out.println("Effective Level for " + lggr.getName() + " is "
> + lggr.getEffectiveLevel());
>
> It says:
>
> Effective Level for com.mainstreamdata.messager is INFO
>
> I don't want INFO; I want DEBUG. If I hadn't set my logger in the config
> file to DEBUG, I would have expected it to default to ERROR (the root logger
> level). I also tried enumerating through the logger repository (off of the
> root logger) to see if I had something misspelled and I really had two
> loggers enabled, but it only shows the one (non-root) logger. Oh, and if I
> set the level programmatically to DEBUG, it works as I expect. Also, I
> printed the effective level of the root logger and it showed up as ERROR
> (which is what I said in the configuration file and so was also expected).
> What am I missing
>
> Thanks for any help.
>
> Scott Smith
>
> -
> 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]
Newbie question on setting different levels
I've been reading through documentation on log4j and thought I understood
how everything works. But there is something I'm missing.
Since several of the Jakarta libraries seem to log to the root logger, I
wanted to set up the root logger with the appenders. Then I would set the
root logger to pass ERROR or above and my own logger to pass DEBUG or above
(so I'd see everything from my app, but only errors from the libraries).
Based on that, I generated the following configuration file.
--
http://jakarta.apache.org/log4j/";
debug="true">
-
When I execute:
DOMConfigurator.configure("log4j.xml");
Everything seems to be fine and I see the following from log4j:
log4j: Threshold ="null".
log4j: Retreiving an instance of org.apache.log4j.Logger.
log4j: Setting [com.mainstreamdata.messager] additivity to [true].
log4j: Level value for com.mainstreamdata.messager is [debug].
log4j: com.mainstreamdata.messager level set to DEBUG
log4j: Level value for root is [error].
log4j: root level set to ERROR
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d [%t] %-5p %c %m%n].
log4j: Adding appender named [CONSOLE] to category [root].
log4j: Class name: [org.apache.log4j.DailyRollingFileAppender]
log4j: Setting property [file] to [./Logs/log].
log4j: Setting property [immediateFlush] to [true].
log4j: Setting property [append] to [true].
log4j: Setting property [datePattern] to ['.' -MM-dd].
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d %-5p %m%n].
log4j: setFile called: ./Logs/log, true
log4j: setFile ended
log4j: Appender [FILE] to be rolled at midnight.
log4j: Adding appender named [FILE] to category [root].
---
All of which looks OK to me. Here's the problem. I don't see any of my
DEBUG logs go to either appender. In fact, if I execute the following line
of code:
System.out.println("Effective Level for " + lggr.getName() + " is "
+ lggr.getEffectiveLevel());
It says:
Effective Level for com.mainstreamdata.messager is INFO
I don't want INFO; I want DEBUG. If I hadn't set my logger in the config
file to DEBUG, I would have expected it to default to ERROR (the root logger
level). I also tried enumerating through the logger repository (off of the
root logger) to see if I had something misspelled and I really had two
loggers enabled, but it only shows the one (non-root) logger. Oh, and if I
set the level programmatically to DEBUG, it works as I expect. Also, I
printed the effective level of the root logger and it showed up as ERROR
(which is what I said in the configuration file and so was also expected).
What am I missing
Thanks for any help.
Scott Smith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: automatic reload
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 > > > wh
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:
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 Watch
RE: automatic reload
Ken, Absolutely. One of the advantages of the "login" approach is that it avoids this problem, since only users who are able to login can trigger the reload. --- regards --- Larry At 01:45 PM 11/11/03, you wrote: BTW, reloading via a servlet in this way has some potential security implications, so tread carefully. Ken > -Original Message- > From: Liu, Ken (C) > Sent: Tuesday, November 11, 2003 3:41 PM > To: [EMAIL PROTECTED] > Subject: RE: automatic reload > > > > 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, > > This is the approach I use. I have a servlet that calls > configure(). I > also have it set up to accept a url parameter, in case I want > to reload a > log4j config file from a url (we developers don't always have > access to the > file system). - 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]
RE: automatic reload
BTW, reloading via a servlet in this way has some potential security implications, so tread carefully. Ken > -Original Message- > From: Liu, Ken (C) > Sent: Tuesday, November 11, 2003 3:41 PM > To: [EMAIL PROTECTED] > Subject: RE: automatic reload > > > > 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, > > This is the approach I use. I have a servlet that calls > configure(). I > also have it set up to accept a url parameter, in case I want > to reload a > log4j config file from a url (we developers don't always have > access to the > file system). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: automatic reload
> 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, This is the approach I use. I have a servlet that calls configure(). I also have it set up to accept a url parameter, in case I want to reload a log4j config file from a url (we developers don't always have access to the file system). > 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. Agreed. I personally feel more confident when I can directly force the reload myself rather than waiting for some thread to silently reload the config. I guess I'm a control freak :) The login approach would work, but I don't personally see any benefit over the servlet approach. Ken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
RE: automatic reload
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
> >
> >
> >
> >
> >>>
> >>>---
> -
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-mai
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]
RE: automatic reload
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]
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]
Re: Re: Using "<level>" (was: Re: Re: Appender logging to 2 logs - how to stop it)
Thank you Jacob/Jake, this helped a lot. Otis Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Mon, 10 Nov 2003, Jacob Kjome ([EMAIL PROTECTED]) wrote: > At 08:40 AM 11/10/2003 -0500, you wrote: > >Hello, > > > >One more question about the use of "" element. > >What is its parent element? > > or (which is the root ) > > >Also, I thought that one controls the level at which logging > >should start by using 's sub-element, like > >this: > > > > > > > > ... > > > > > >I thought this meant "log at INFO level or above (WARN, ERROR, > >FATAL), but do not log below it (DEBUG)". > > > >Am I wrong? > > Not completely. These are slightly different concepts, though. is > used to set the logger priority where using threshold on an appender > creates a filter for loggers with certain levels. The threshold filter is > useful when defining multiple appenders for a logger or set of > loggers. You do the same sort of filtering if you create an appender > without a threshold filter and use... > > > > > > > >Is that actually dictated by the element? If so, what > >is the purpose of this Threshold parameter? > > see above. > > >Thank you, > >Otis > > Jake > > > > > > > > >Get your own "800" number > >Voicemail, fax, email, and a lot more > >http://www.ureach.com/reg/tag > > > > > > On Fri, 07 Nov 2003, Jacob Kjome ([EMAIL PROTECTED]) wrote: > > > > > > > > 1. You should use , not > > > 2. If you don't want to inherit logging from the > >logger, you should > > > add additivity="false" to the UserTracker > > > 3. You might want to set the 's you prefer as well > > > > > > Jake > > > > > > At 12:06 PM 11/7/2003 -0500, you wrote: > > > >Hello, > > > > > > > >I am using log4j 1.2.8 (under JBoss). I'm having a problem > >with > > > >one of my Appenders logging to multiple log files, even > >though I > > > >didn't configure it to do this. > > > > > > > >Here is how I configured it: > > > > > > > > > > >class="..DailyRollingFileAppender"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >That is it. > > > > > > > >The log4j.xml also contains configs for several other > >appenders, > > > >and contains this: > > > > > > > > > > > > > > > > > > > > > > > > > > > >CONSOLE is a ConsoleAppender catching System.out and FILE is > >a > > > >DailyRollingFileAppender going to a different log file. > > > > > > > > > > > >It seems to me like messages going to my UserTracker > >appender > > > >are somehow getting saved into the CONSOLE appender. > > > >Nothing in my code prints to System.out. > > > > > > > >I have not been able to figure this out for a looong time. > > > >Does anyone know how to prevent this from happening? > > > > > > > >Thanks, > > > >Otis > > > > > > > > > > > > > > > >Get your own "800" number > > > >Voicemail, fax, email, and a lot more > > > >http://www.ureach.com/reg/tag > > > > > > > > > >- > > > >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]
