commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Kapitza <j.kapi...@schwarze-allianz.de>
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 <grobmeier@gmail.com> 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:
>> https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html
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 <grobmeier@gmail.com> </div><div>Date:11/30/2014  16:27
 (GMT-05:00) </div><div>To: Commons Developers List <dev@commons.apache.org>
</div><div>Cc:  </div><div>Subject: [logging] Commons Logging 2.0?
</div><div>
>>>> </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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message