commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [logging] Commons Logging 2.0?
Date Mon, 01 Dec 2014 18:45:09 GMT
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 <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.

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 <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