commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <siegfried.goes...@it20one.com>
Subject Re: [logging] Commons Logging 2.0?
Date Mon, 01 Dec 2014 21:15:41 GMT
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 <grobmeier@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 <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
>>> 
>> 
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message