commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [logging] Cleanup of trunk
Date Sat, 12 Jan 2013 19:49:57 GMT
On 12/01/2013 19:29, Christian Grobmeier wrote:
> On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <> wrote:
>> On 12/01/2013 17:36, Christian Grobmeier wrote:
>>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>>> use for old and older applications.
>>> That said, I just checked and saw tomcat is still using commons-logging:
>>> Maybe Mark will comment here.
>> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
>> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
>> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
>> the latest version is.
> Just out of interest... why the love with Commons Logging and not for
> example slf4j?

It was the best choice at the time and no-one has made a good argument
for changing.

Tomcat used C-L to create JULI which is package renamed (to avoid
conflicts if a webapp uses C-L), hard coded to use java.util.logging and
has a custom LogManager that actually works properly in a
multi-classloader container environment - don't get me started on how
bad the default one is.

There is an optional package that adds back in the (still package
renamed) full version of commons logging and provides an adaptor for log4j.

So Tomcat's requirements are:
- easy to package rename (technically and legally)
- pluggable for multiple back-ends
- won't clash with anything a webapp does

Commons Logging meets all of those requirements. Other logging
frameworks may also meet them but they'd have to offer an awful lot more
to justify the work that would be required to refactor JULI to use them.
It isn't as if there are any features missing in C-L that Tomcat


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message