Re: [Springframework-developer] Commons Logging

[Isabelle M. <isa...@me...>]

Hi Juergen,

Sounds good to me!

Isabelle

On Wed, May 28, 2003 at 04:17:20PM +0200, jürgen höller [werk3AT] wrote:
> 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 = 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ürgen Höller
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com