commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [Configuration] experimental branch uses java.util.logging?
Date Mon, 22 Jun 2009 21:47:35 GMT
Rahul Akolkar wrote:

> On Fri, Jun 19, 2009 at 11:07 AM, Emmanuel Bourg<> wrote:
>> Ralph Goers a écrit :
> <snip/>
>>> 2. In all the various logging discussions that have taken place on this
>>> list in the last few months, many initiated by me, the concensus seems
>>> to be that commons logging is the logging framework that should be used
>>> by commons projects. Although not my preference I will abide by that.
>> The consensus is nobody wants to engage in a heated discussion about
>> logging ever again. We have wasted too much time on this topic.
> <snap/>
> Sigh, indeed.
>> So the default
>> choice wins, that's Commons Logging. But that choice is just inherited
>> from the Java 1.3 compatibility era.
> <snip/>

it is as Don said, in a JEE environment JUL is really the worst choice. We
have some global players as customers and they have all very specific
requirements regarding logging to ensure their monitoring process of the
life systems. This is in the range of using a very special format up to
using their logger framework. If you deliver a EAR or WAR you cannot
control the format of JUL at all, since a JUL-formatter must be available
at the server path. Additionally it is not possible to provide an alternate
implementation. I am quite sure that cc2 with JUL would force us to create
an internal fork. JULI for Tomcat only works *because* they are the server.
> And two principles:
> 1. Minimal disruption. Commons is widely used, such that for released
> components, anything that causes any amount of disruption to users is
> no good.
> 2. Communal responsibility. Commons libraries tend to be used in
> bunches. Its good when we are consistent in logging. Historically,
> most Commons libraries have used CL.

If we really want to think about a next generation CL and agree that the
approach SLF4J has taken is te right one, then I'd rather move CL 1.x into
maintenance mode and use SLF4J directly instead of reinventing the wheel.
However, that move should be done then for all commons components because
of reason 2.

- Jörg

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

View raw message