commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Kapitza <>
Subject Re: [logging] Commons Logging 2.0?
Date Mon, 01 Dec 2014 17:41:26 GMT
Hi, just reading through the list i'll come up with some comments below

Am 01.12.2014 um 18:04 schrieb sebb:
> On 1 December 2014 at 09:28, Christian Grobmeier <> wrote:
>> On Mon, Dec 1, 2014, at 00:50, sebb wrote:
>>> But it would be interesting to know why the Spring dev thought a new
>>> version would be useful.
>> The team seemed to discuss moving to slf4j, but he mentioned they were
>> happy not doing it since the learned about bc breaks within slf4j
>> versions. In general he was totally enjoying that CL "just works".
>> However he appeared to miss some things which make logging-lifes easier,
>> like String substitution in:
>> log.debug("Hello {} {}", a.getGivenName(), a.getName());
>> More specifically he mentioned MessageFormat support:
this would be great (but ... @see below).

Stringsubstitution allows much better code-writing.
>> This is something all logging frameworks seem to support and which might
>> be possible to add without breaking things.
>> Current:
>> debug(Object message)
>> debug(Object message, Throwable t)
>> Addition:
>> debug(Object o, Object... args) {}
>> That aside, I would do the following:
>>   - jdk support for at least >7 (varargs need 5, but MessageFormat 7)
like commons-lang3, commons-io there is still support for Java6,
so i think i would be better to not support  MessageFormat  directly 
(maybe via refelction?)
and get it run with a simple own solution if JVM < 1.7.

> -1 if this means that CL no longer works on earlier versions of Java.
>>   - remove AvalonLogger and LogKitLogger
> Why?

avalon-framework was moved to attic? and in my opinion it would be gread to tidy up -  and
check the versions (maybe update servlet-api, junit)

> AFAIK they just work, so why drop them?
maybe build a separate module for them
>>>> For anything more I would point to log4j 2.
>>>> Gary
>>>> <div>-------- Original message --------</div><div>From:
Christian Grobmeier <> </div><div>Date:11/30/2014  16:27
 (GMT-05:00) </div><div>To: Commons Developers List <>
</div><div>Cc:  </div><div>Subject: [logging] Commons Logging 2.0?
>>>> </div>Hi folks,
>>>> I am perfectly aware that I was saying CL needs to be deprecated only
>>>> before month.
>>>> Tomcat uses CL and that was more or less the reason it would stay - so I
>>>> thought.
>>>> Recently I talked to a person actively involved in Spring. He explained,
>>>> Spring would use
>>>> CL and they are quite happy with it. Reason: it's always the same.
>>>> He also told me that - rather having a new JSR with new interfaces which
>>>> would be difficult to get into the JDK - he would love to have some kind
>>>> of CL 2.0.
>>>> To be honest, it made me think and reconsider whatever I have thought or
>>>> said in the past. I know Mark did say similar things, but maybe it is
>>>> the power of a direct conversation.
>>>> I am still unsure if a CL 2.0 would be needed or not and thats why I
>>>> outreach here to ask for your feelings/opinions whatever.
>>>> We have a Log4j2 which is really good. We have a slf4j which is fine.
>>>> And we have a CL 1.x which is, well dated.
>>>> Would it make sense to have a CL 2.0 which is more or less (maybe with
>>>> small adjustments, despite the major version jump) a drop in
>>>> replacement? It could just add some methods or things like variable
>>>> substitutions, and thats it. Nothing big. Modern JVM support, some more
>>>> methods. The rest all the same, except log4j 2 support (which is also
>>>> provided by the log4j project).
>>>> As mentioned I am still undecided. But CL 2.0 could be a minimal
>>>> interface for consumers looking for stability instead of tons of
>>>> features. However a bit more "modern taste" doesn't hurt, as long as it
>>>> doesn't break things (too much).
>>>> Thoughts?
>>>> Christian
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message