On Mon, Dec 1, 2014, at 14:31, Gary Gregory wrote:
> FWIW, I think a new version of CL would be 'fun' if it included support
> for
> Log4j 2...
Agreed. :)
>
> Gary
>
> On Mon, Dec 1, 2014 at 7:57 AM, Gary Gregory <garydgreg...@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 <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)
> >> - remove AvalonLogger and LogKitLogger
> >>
> >>
> >> >
> >> > > 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
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@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: garydgreg...@gmail.com | ggreg...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
