commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [logging] Commons Logging 2.0?
Date Mon, 01 Dec 2014 13:31:35 GMT
FWIW, I think a new version of CL would be 'fun' if it included support for
Log4j 2...

Gary

On Mon, Dec 1, 2014 at 7:57 AM, Gary Gregory <garydgregory@gmail.com> wrote:

> MessageFormat? WRT Log4j 2: So there's another thing to compare WRT to performance and
String.format and our own {} support... any thoughts on that?
>
> Gary
>
>
> On Mon, Dec 1, 2014 at 4:28 AM, 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 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)
>>  - remove AvalonLogger and LogKitLogger
>>
>>
>> >
>> > > 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
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message