commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: [logging] Cleanup of trunk
Date Tue, 15 Jan 2013 08:56:51 GMT
On Sat, Jan 12, 2013 at 8:49 PM, Mark Thomas <> wrote:
> 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
> needs/wants.

Thanks for the insight.

Maybe it would be interesting to change the targets of commons-logging.

Currently it is in direct competition with slf4j (logging facade which
connects to different other frameworks). And as that its pretty
outdated and just of use for a few.

But what if commons-logging would have the target to be minimal, easy
to repackage and maybe does even provide a basic logging

The other frameworks come up with a lot of features which often comes
with a lot of complexity and sometimes a cost in performance.
commons-logging could solve this.


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


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

View raw message