[Springframework-developer] Commons Logging

[<jue...@we...>]

Hi Rod, JP, Isabelle, everybody,

As there seems to be the time for basic issues... ;-)

I've been thinking about using Commons Logging for quite a while, =
instead of Log4J directly. Initially I've been somewhat sceptical about =
its value, especially regarding the drawback of tricky classloader =
issues that might arise in a container environment. But Commons Logging =
1.0.3 works without hassle in Tomcat 4.0, Tomcat 4.1, and Resin 2.1 - =
both with and without Log4J. The release notes say that they've been =
working busily on proper behavior within a container, using the thread =
context class loader everywhere now.

If Log4j is present in either WEB-INF/lib or the container's common lib =
directory, Log4J is chosen by default. If not and running on J2SE 1.4, =
JDK logging gets used. On J2SE 1.3, the fallback is a simple console =
logger. You can explicitly configure the implementation too, via a =
commons-logging.properties file in the classpath, or via VM parameters.

I've tried a lot of combinations: Both commons-logging.jar and log4j.jar =
in each WEB-INF/lib, both in common lib, commons-logging in WEB-INF/lib =
+ log4j.jar in common lib - all of them work in Tomcat and Resin. =
There's only one combo that doesn't work: commons-logging.jar just in =
common lib + log4j.jar in WEB-INF/lib. The latter with a commons-logging =
copy in WEB-INF/lib does work. So there's only one definitive rule: Keep =
a commons-logging.jar in your WEB-INF/lib.

Today I've prototyped using Commons Logging within Spring, and it works =
nicely - I just had to exchange the Log4J Logger declarations with the =
following:

	protected final Log logger =3D LogFactory.getLog(getClass());

A Commons Logging Log object is very similar to a Log4J Logger object, =
mirroring the Log4J API closely. The configuration and runtime impact is =
negligible - you probably wouldn't even recognize that Commons Logging =
is used after refreshing from CVS, as Log4J still gets used by default, =
applying any Log4J configuration that was there before.

My main intent is to support as many environments as possible. At =
werk3AT, we've recently considered using Spring in an applet (yep, =
they're still around), debating about the inclusion of Log4J in the =
download. Just depending on Commons Logging would ease such things =
significantly, as its JAR is just 31 KB including all wrapper =
implementations! A even slimmer version is provided too, containing just =
the J2SE 1.4 logger and the simple one - in 22 KB.

Both Hibernate and Kodo JDO use Commons Logging too, so we would be in =
good neighborhood. And it seems that we wouldn't lose anything, not even =
simplicity. All things considered, I vote for changing to Commons =
Logging promptly (I could check it in this evening). What do you think? =
Any objections?

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG