commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Affan Qureshi" <quere...@etilize.com>
Subject Re: [logging] How to setLevel() for commons logging? (urgent :)
Date Fri, 11 Apr 2003 10:18:55 GMT
I found this very intersting thread on mail-archive.com and wanted to
implement something similar. I have a webapp with Struts on Tomcat 4.1.18
under JDK 1.4. The problem is to configure Log4J programmatically through
the admin web interface which doesn't seem to work with a property file.

I thought if you could provide me with some example or guide me to resources
on how to implement programmatic configuration of Log4J running under
commons-logging in a webapp in Tomcat.

Thanks a lot.

Affan

> >From: Thomas Nichols
> >Subject: Re: [logging] How to setLevel() for commons logging? (urgent :)
> >Date: Thu, 03 Apr 2003 11:57:07 -0800
> >
> >
> >At 11:24 03/04/2003 -0800, Craig R. McClanahan wrote:
> >
> >
> >
> >On Thu, 3 Apr 2003, Thomas Nichols wrote:
> >
> >[snip]
> >
> >
> >Why don't you just let the underlying logging system configure itself
> >based on properties files (log4j.properties for Log4J, logging.properties
> >for JDK 1.4)?  Then you have zero code dependencies, and only need to
> >make sure that the correct properties file is visible.  Programmatic
> >initialization of stuff like this is a lot more painful.
> >
> >
> >More painful - yes. But it gives me fine control without requiring that a
> >properties file be present. I'm re-examining my reasons for wanting this,
> >but my thinking was to get "default" (no props files found) behaviour
that
> >works as I expect. Maybe the advantages of this are illusory :)
> >
> >
> >
> >The other thing to remember is that, at least for the default c-l
> >implementations, the object you get directly from Log4J:
> >
> >Logger logger = Logger.getLogger("com.mycompany.mypackage.Foo");
> >
> >is the exact same one that is wrapped by c-l:
> >
> >Log log = LogFactory.getLog("com.mycompany.mypackage.Foo");
> >
> >
> >so configuration changes on the former will be reflected in the behavior
> >of the latter (it's just a wrapper).
> >
> >
> >(Dull thud as penny drops). This does exactly what I was trying to do -
> >though now I'm not so sure it's the best solution...
> >
> >
> >This is only guaranteed if you're using the default implementations in
> >c-l.  But, as stated above, I would still avoid programmatic
> >initialization totally if you can.  Zero implementation-classes is
> >infinitely better than one :-).
> >
> >Craig
> >
> >Thank you for taking the time to explain the options here - a plethora of
> >choices!
> >
> >
> >Best Regards,
> >Thomas.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>


Mime
View raw message