You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2014/12/01 00:50:06 UTC
Re: [logging] Commons Logging 2.0?
On 30 November 2014 at 21:57, Gary Gregory <ga...@gmail.com> wrote:
> 2.0 would mean breaking BC to me.
Not necessarily. A big jump in minimum Java version might deserve a
major version bump.
> Keep it at 1.x to convey a warm and fuzzy feeling of compatibility.
Compatibility is not guaranteed by keeping the same major version number.
What's important is whether it really is compatible or not, and that
needs to be clearly documented.
> I would keep the changes to a minimum.
Here, I agree.
If it ain't broke, don't try and fix it.
But it would be interesting to know why the Spring dev thought a new
version would be useful.
> For anything more I would point to log4j 2.
>
> Gary
>
> <div>-------- Original message --------</div><div>From: Christian Grobmeier <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
Re: [logging] Commons Logging 2.0?
Posted by Jens Kapitza <j....@schwarze-allianz.de>.
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 <gr...@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 <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
Re: [logging] Commons Logging 2.0?
Posted by Curt Arnold <cu...@gmail.com>.
If you want to drive into this, you may want to review the LogMF and LogSF companions and related discussion in the archives.
The cost of the array construction implicit in a vararg call and the cost of boxing scalars can dwarf the cost of determining whether to log or not. Unfortunately those activities occur unconditionally prior to determining whether the request is above the threshold. Doesn't matter much when a message goes to an appender but makes the no-op call substantially more expensive.
The LogMF and LogSF companions defined a substantial number of overloads so that you'd rarely call the vararg implementation and take its performace hit. It had to target JDK 1.4 so it couldn't use templates and might be more elegantly written without that limitation.
LogMF used the message format syntax but optimized the trivial string substitution case to avoid poor performance for the simple cases while it defers to the JDK implementation for the atypical cases. Resulting in performance that was indistinguishable from LogSF which used the SLF4J format specifiers while still preserving the much richer capabilities. Their should also be discussion around a LogF which would use the new at the time JDK 5 formatted bit I don't recall that much about it.
It was the only means I could find to add vararg like capability to log4j 1 without breaking compatibility, but I thought it came out fairly well.
Sent from my iPhone
> On Dec 1, 2014, at 3:15 PM, Siegfried Goeschl <si...@it20one.com> wrote:
>
> Hi Christian,
>
> one of those unlikely users of Avalon is the Turbine framework but I can lend a hand with AvalonLogger :-)
>
> Cheers,
>
> Siegfried Goeschl
>
>> On 01 Dec 2014, at 19:17, Christian Grobmeier <cg...@grobmeier.de> wrote:
>>
>> On Mon, Dec 1, 2014, at 18:04, sebb wrote:
>>> On 1 December 2014 at 09:28, Christian Grobmeier <gr...@gmail.com>
>>> wrote:
>>>> That aside, I would do the following:
>>>>
>>>> - jdk support for at least >7 (varargs need 5, but MessageFormat 7)
>>
>> Just saw MessageFormat is even available in jdk 5. So I would opt for
>> this one.
>>
>>> -1 if this means that CL no longer works on earlier versions of Java.
>>
>> -1? haha come on, what versions would you like to support? :) Jdk 1.3 is
>> dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be
>> allowed to work with more recent jdks. I can't even install that old
>> versions on my mac. If you want to block any innovation then keep that
>> approach of supporting 1.3.
>>
>> Spring needs Java 6, unarchived Tomcat versions require Java >5.
>> We can discuss Java 5, but I am definitely not doing anything when I
>> need to install a vm to test with 1.3.
>>
>>>> - remove AvalonLogger and LogKitLogger
>>>
>>> Why?
>>>
>>> AFAIK they just work, so why drop them?
>>
>> Why keeping them? The frameworks are dead for ages, it's unlikely users
>> of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would
>> implement these methods for that frameworks, you are welcome.
>>
>> You need touch them to implement the new logging methods.
>>
>> Cheers
>> Christian
>>
>>>
>>>>
>>>>>
>>>>>> For anything more I would point to log4j 2.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> <div>-------- Original message --------</div><div>From: Christian Grobmeier <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
>
>
> ---------------------------------------------------------------------
> 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
Re: [logging] Commons Logging 2.0?
Posted by Siegfried Goeschl <si...@it20one.com>.
Hi Christian,
one of those unlikely users of Avalon is the Turbine framework but I can lend a hand with AvalonLogger :-)
Cheers,
Siegfried Goeschl
> On 01 Dec 2014, at 19:17, Christian Grobmeier <cg...@grobmeier.de> wrote:
>
> On Mon, Dec 1, 2014, at 18:04, sebb wrote:
>> On 1 December 2014 at 09:28, Christian Grobmeier <gr...@gmail.com>
>> wrote:
>>> That aside, I would do the following:
>>>
>>> - jdk support for at least >7 (varargs need 5, but MessageFormat 7)
>
> Just saw MessageFormat is even available in jdk 5. So I would opt for
> this one.
>
>> -1 if this means that CL no longer works on earlier versions of Java.
>
> -1? haha come on, what versions would you like to support? :) Jdk 1.3 is
> dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be
> allowed to work with more recent jdks. I can't even install that old
> versions on my mac. If you want to block any innovation then keep that
> approach of supporting 1.3.
>
> Spring needs Java 6, unarchived Tomcat versions require Java >5.
> We can discuss Java 5, but I am definitely not doing anything when I
> need to install a vm to test with 1.3.
>
>>> - remove AvalonLogger and LogKitLogger
>>
>> Why?
>>
>> AFAIK they just work, so why drop them?
>
> Why keeping them? The frameworks are dead for ages, it's unlikely users
> of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would
> implement these methods for that frameworks, you are welcome.
>
> You need touch them to implement the new logging methods.
>
> Cheers
> Christian
>
>>
>>>
>>>>
>>>>> For anything more I would point to log4j 2.
>>>>>
>>>>> Gary
>>>>>
>>>>> <div>-------- Original message --------</div><div>From: Christian Grobmeier <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Commons Logging 2.0?
Posted by sebb <se...@gmail.com>.
On 1 December 2014 at 18:17, Christian Grobmeier <cg...@grobmeier.de> wrote:
> On Mon, Dec 1, 2014, at 18:04, sebb wrote:
>> On 1 December 2014 at 09:28, Christian Grobmeier <gr...@gmail.com>
>> wrote:
>> > That aside, I would do the following:
>> >
>> > - jdk support for at least >7 (varargs need 5, but MessageFormat 7)
>
> Just saw MessageFormat is even available in jdk 5. So I would opt for
> this one.
>
>> -1 if this means that CL no longer works on earlier versions of Java.
>
> -1? haha come on, what versions would you like to support? :) Jdk 1.3 is
> dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be
> allowed to work with more recent jdks. I can't even install that old
> versions on my mac. If you want to block any innovation then keep that
> approach of supporting 1.3.
I did not say it needed to continue to support 1.3.
> Spring needs Java 6, unarchived Tomcat versions require Java >5.
Exactly.
The post to which I replied implied that CL would require Java 7+
That is what I was vetoing.
> We can discuss Java 5, but I am definitely not doing anything when I
> need to install a vm to test with 1.3.
I never wrote that.
>> > - remove AvalonLogger and LogKitLogger
>>
>> Why?
>>
>> AFAIK they just work, so why drop them?
>
> Why keeping them? The frameworks are dead for ages
Because they are still used, and they still work.
Just because a product is in the Attic does not stop it working.
> , it's unlikely users of Avalon might ever tend to upgrade to CL 2.0.
If the MessageFormat were implemented and supported by Avalon, then it
is quite possible that users would upgrade.
> Of course, if you would
> implement these methods for that frameworks, you are welcome.
>
> You need touch them to implement the new logging methods.
Not necessarily; it depends where the formatting is done.
> Cheers
> Christian
>
>>
>> >
>> >>
>> >> > For anything more I would point to log4j 2.
>> >> >
>> >> > Gary
>> >> >
>> >> > <div>-------- Original message --------</div><div>From: Christian Grobmeier <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Commons Logging 2.0?
Posted by Christian Grobmeier <cg...@grobmeier.de>.
On Mon, Dec 1, 2014, at 18:04, sebb wrote:
> On 1 December 2014 at 09:28, Christian Grobmeier <gr...@gmail.com>
> wrote:
> > That aside, I would do the following:
> >
> > - jdk support for at least >7 (varargs need 5, but MessageFormat 7)
Just saw MessageFormat is even available in jdk 5. So I would opt for
this one.
> -1 if this means that CL no longer works on earlier versions of Java.
-1? haha come on, what versions would you like to support? :) Jdk 1.3 is
dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be
allowed to work with more recent jdks. I can't even install that old
versions on my mac. If you want to block any innovation then keep that
approach of supporting 1.3.
Spring needs Java 6, unarchived Tomcat versions require Java >5.
We can discuss Java 5, but I am definitely not doing anything when I
need to install a vm to test with 1.3.
> > - remove AvalonLogger and LogKitLogger
>
> Why?
>
> AFAIK they just work, so why drop them?
Why keeping them? The frameworks are dead for ages, it's unlikely users
of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would
implement these methods for that frameworks, you are welcome.
You need touch them to implement the new logging methods.
Cheers
Christian
>
> >
> >>
> >> > For anything more I would point to log4j 2.
> >> >
> >> > Gary
> >> >
> >> > <div>-------- Original message --------</div><div>From: Christian Grobmeier <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
Re: [logging] Commons Logging 2.0?
Posted by sebb <se...@gmail.com>.
On 1 December 2014 at 09:28, Christian Grobmeier <gr...@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 <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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
Re: [logging] Commons Logging 2.0?
Posted by Gary Gregory <ga...@gmail.com>.
Rainer,
Is there anything on the Log4j 2 side that would make this easier or
better? If so, would you be willing to raise a JIRA with Log4j 2. FYI: I am
on the Apache Logging PMC and have been quite involved in Log4j 2.
Gary
On Sun, Dec 14, 2014 at 2:38 PM, Rainer Jung <ra...@kippdata.de>
wrote:
>
> Am 01.12.2014 um 14:31 schrieb Gary Gregory:
>
>> FWIW, I think a new version of CL would be 'fun' if it included support
>> for
>> Log4j 2...
>>
>
> I did an experiment in Tomcat land, because I didn't like the way Log4J
> version 2 supported commons-logging. Originally if you want to plug log4j
> version 2 into commons-logging, you need to add the log4j jar files to the
> same class loader that loaded commons-logging. For log4j Version 1 that is
> not true. Its integration in commons-logging can find log4j even if the
> class using commons-logging is loaded by a class loader lower down and
> log4j can be found by that classloader.
>
> Furthermore if you use the log4j version 2 integration, it replaces the
> factory that searches for log implementations and hard codes log4j version
> 2 only.
>
> So I used the existing log4j version 2 classes and slightly adjusted them
> for inclusion into commons logging. The result can be found at
>
> http://people.apache.org/~rjung/patches/cl-log4j2.patch
>
> That would be one way of supporting log4j version 2 in commons logging in
> a way that's completely analogous to the log4j version 1 support.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> 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
Re: [logging] Commons Logging 2.0?
Posted by Rainer Jung <ra...@kippdata.de>.
Am 01.12.2014 um 14:31 schrieb Gary Gregory:
> FWIW, I think a new version of CL would be 'fun' if it included support for
> Log4j 2...
I did an experiment in Tomcat land, because I didn't like the way Log4J
version 2 supported commons-logging. Originally if you want to plug
log4j version 2 into commons-logging, you need to add the log4j jar
files to the same class loader that loaded commons-logging. For log4j
Version 1 that is not true. Its integration in commons-logging can find
log4j even if the class using commons-logging is loaded by a class
loader lower down and log4j can be found by that classloader.
Furthermore if you use the log4j version 2 integration, it replaces the
factory that searches for log implementations and hard codes log4j
version 2 only.
So I used the existing log4j version 2 classes and slightly adjusted
them for inclusion into commons logging. The result can be found at
http://people.apache.org/~rjung/patches/cl-log4j2.patch
That would be one way of supporting log4j version 2 in commons logging
in a way that's completely analogous to the log4j version 1 support.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Commons Logging 2.0?
Posted by Christian Grobmeier <cg...@grobmeier.de>.
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 <ga...@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 <gr...@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 <gr...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Commons Logging 2.0?
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@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 <gr...@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 <gr...@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
Re: [logging] Commons Logging 2.0?
Posted by Christian Grobmeier <gr...@gmail.com>.
On Mon, Dec 1, 2014, at 13:57, Gary Gregory 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?
No, didn't think about this yet. I just pass on what I was told without
judgement for now
Christian
>
> Gary
>
>
> On Mon, Dec 1, 2014 at 4:28 AM, Christian Grobmeier <gr...@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 <gr...@gmail.com> </div><div>Date:11/30/2014 16:27
> > (GMT-05:00) </div><div>To: Commons Developers List <de...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] Commons Logging 2.0?
Posted by Gary Gregory <ga...@gmail.com>.
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 <gr...@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 <gr...@gmail.com> </div><div>Date:11/30/2014 16:27
> (GMT-05:00) </div><div>To: Commons Developers List <de...@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
Re: [logging] Commons Logging 2.0?
Posted by Christian Grobmeier <gr...@gmail.com>.
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 <gr...@gmail.com> </div><div>Date:11/30/2014 16:27 (GMT-05:00) </div><div>To: Commons Developers List <de...@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