commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [logging] How to setLevel() for commons logging? (urgent :)
Date Thu, 03 Apr 2003 19:24:33 GMT

On Thu, 3 Apr 2003, Thomas Nichols wrote:

> >Of course, if you find it necessary to access these logger objects, it
> >seems to me that using commons-logging is a waste of time -- you're going
> >to be tying yourself to the underlying implementation anyway.
> I can live with a Log4J dependency in a single source file, but I don't
> want such dependencies scattered throughout the code. Such an architecture
> would even allow me to have a controller class select either Log4J or JDK14
> logging at startup based on user prefs - to do this it would be very handy
> to have access to the internals of the instantiated logger to perform
> custom setup. It seems this is exactly what I get from your suggestion of a
> custom LogFactory - and commons-logging stays clean and within scope :-)

Why don't you just let the underlying logging system configure itself
based on properties files ( for Log4J,
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.

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).

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 :-).

> Thanks again,
> Thomas.


View raw message