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]
