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 <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 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 <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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
