On 1 December 2014 at 09:28, Christian Grobmeier <grobme...@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)
-1 if this means that CL no longer works on earlier versions of Java.
> - remove AvalonLogger and LogKitLogger
Why?
AFAIK they just work, so why drop them?
>
>>
>> > For anything more I would point to log4j 2.
>> >
>> > Gary
>> >
>> > <div>-------- Original message --------</div><div>From: Christian
>> > Grobmeier <grobme...@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-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
