http://logging.apache.org/log4j/docs/api/org/apache/log4j/jmx/package-summary.html
ConfigureAndWatch works well ,but it is more cumbersome on the cluster, and it requires dependency on the file system location which is error prone.
----- Original Message ----- From: "Mike Curwen" <[EMAIL PROTECTED]>
To: "'Tomcat Users List'" <[email protected]>
Sent: Friday, January 21, 2005 3:50 PM
Subject: RE: reload log4j.properties on-the-fly?
Right, so you want to configure *tomcat* logging on the fly, but not a web-app's.
The scenario might be:
Production box with Tomcat logging set to "ERROR" starts behaving oddly, perhaps throwing a lot of "ERROR" level messages. To help diagnose, you want to dynamically enable more verbose logging (WARN, INFO) for *tomcat* logging.
Hmm... Tomcat uses commons-logging, so there'd need to be a way to get commons-logging to reload its configuration. I stay away from commons-logging as much as I can, so no help from me. But if Tomcat doesn't already support it, then you're looking at tweaking tomcat source to get what you want, and that's if commons-logging lets you do it.
p.s. to Julius:
Both of your suggestions are just TOO easy... and here I've been afraid of looking into this. Thanks!
Mike Curwen
-----Original Message----- From: Andy Kriger [mailto:[EMAIL PROTECTED] Sent: Friday, January 21, 2005 1:33 PM To: [email protected] Subject: Re: reload log4j.properties on-the-fly?
To clarify - an initialization servlet defined in conf/web.xml will be able to reload the log4j config used by the Tomcat server (remember we're not talking about webapps)?
On Fri, 21 Jan 2005 14:18:22 -0500, Derrick Koes <[EMAIL PROTECTED]> wrote: > > Use the configureAndWatch method of a configurator in an > initialization servlet. > > -----Original Message----- > From: Andy Kriger [mailto:[EMAIL PROTECTED] > Sent: Friday, January 21, 2005 2:06 PM > To: [email protected] > > Subject: Re: reload log4j.properties on-the-fly? > > Right - I have logging in WEB-INF/classes that I can reload by > reloading the webapp (not a big deal). > > What I'd like is to be able to reload the Tomcat logging (which uses > log4j in common/lib and configured in common/classes) without having > to restart Tomcat. It's a bit extreme to restart the server just to > change logging levels for an specific situation. > > On Fri, 21 Jan 2005 12:55:15 -0600, Mike Curwen > <[EMAIL PROTECTED]> wrote: > > Ah, then it wouldn't work at all. I failed to see you say > > "common/classes". > > > > It's probably the preferred option to put it in WEB-INF/classes > > though (not to mention a log4j.jar file per app in WEB-INF/lib). > > That way you can independantly control logging for each of your > > apps, plus your logging config won't interfere with Tomcat's > > internal logging (which many people experience, when they try to do > > the common/lib approach). > > > > Mike Curwen > > Product Manager > > Globally Boundless > > www.globallyboundless.com > > 204.885.7733 ext 227 > > > > -------------------------------------------------------------------- > > -- > > ------ > > ---- > > Privacy Compliance: This e-mail message is intended only for the use > > of the individual or entity to which it is addressed, and may contain > > information that is privileged, confidential and exempt from > > disclosure under applicable law. Any other distribution, copying or disclosure is strictly prohibited. > > If you have received this message in error, please notify us > > immediately by telephone (800) 665-1321 and reply to the sender via > > e-mail, confirming deletion of the original e-mail and any attachment(s). > > > > -------------------------------------------------------------------- > > -- > > ------ > > ---- > > > > > > > -----Original Message----- > > > From: Andy Kriger [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, January 21, 2005 12:26 PM > > > To: Mike Curwen > > > Subject: Re: reload log4j.properties on-the-fly? > > > > > > > > > In the first case, since log4j.properties is in the global Tomcat > > > classes dir - would that reload every Context? > > > > > > > > > On Fri, 21 Jan 2005 12:19:48 -0600, Mike Curwen > > > <[EMAIL PROTECTED]> wrote: > > > > There's two approaches. > > > > > > > > Configure tomcat to reload the context when class changes are > > > > made (log4j.properties being in the classes directory, will > > > > count as a class being changed, and then the whole context will > > > reload). We do > > > > this all the time. > > > > > > > > Log4j can be used in a manner where config changes are > > > discovered at > > > > run-time, though I've never tried it (and you should ask > > > about in on > > > > the log4j-user list) > > > > > > > > Mike Curwen > > > > > > > > > > > > > -----Original Message----- > > > > > From: Andy Kriger [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, January 21, 2005 12:03 PM > > > > > To: [email protected] > > > > > Subject: reload log4j.properties on-the-fly? > > > > > > > > > > > > > > > I am running Tomcat 5.5 with log4j logging (log4j.properties > > > > > in common/classes). > > > > > > > > > > Is it possible to make changes to the log4j properties > > > and have the > > > > > changes reloaded on-the-fly instead of having to restart > > > Tomcat in > > > > > order to pick up changes? This would be very useful for > > > those times > > > > > debug level logging or specific class logging is needed where > > > > > generally that level of logging is not required. > > > > > > > > > > thx > > > > > andy > > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > > > - > > > > > 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]
