logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Petrelli <antonio.petre...@gmail.com>
Subject Re: will there be a parameterized message in log4j like it is in slf4j?
Date Mon, 05 Oct 2009 15:28:50 GMT
Ceki, Curt
I suppose that this discussion is becoming too much personal.
Please continue your discussion privately.

Antonio

2009/10/5 Ceki Gulcu <ceki@qos.ch>:
>
>
> Curt Arnold wrote:
>>
>> On Oct 5, 2009, at 5:39 AM, Ceki Gulcu wrote:
>>
>>> Betrayal is a big word to associate with a facility,
>>> i.e. ObjectRenderer, which hardly anyone uses, especially since there
>>> are other ways of transforming an Object into a String. In a
>>> widely-used project like log4j, it is easy to dig one's heels so as to
>>> prevent change based on the backward compatibility argument.
>>
>>>
>>> The changes I am proposing will affect an extremely small minority,
>>> say less than 1 user in 100'000,
>>
>> Jess Holle immediately responded when the idea was floated that it would
>> break his use of log4j.  Usage questions on non-String first parameters
>> comes up often enough on the mailing list that it cannot be just 1/100,000
>> of users.
>
> Jess Holle has indeed reacted pretty quickly. For any popular library,
> there will be users who react negatively to proposed changes. The
> 1/100'000 is probably too low an estimation. However, it is accurate to
> say that the number of users who would benefit from logging
> consolidation far outnumber those who would be negatively affected by
> the Object->String change. It should also be noted that the
> Object->String change does not mean that messages of type Object
> cannot be passed to log4j. They just need to be passed differently.
>
>> I'm not aware of an Apache java compatibility statement, but Eclipse has
>> one, http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs.  The
>> technical description of binary compatibility in Java is described in
>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html.  The
>> build.xml does CLIRR (http://clirr.sourceforge.net/).  I do not believe I
>> have ever made a backwards compatibility argument that went beyond those.
>
> In the context of an highly extensible framework like log4j, if
> perfect backward compatibility were needed, it would be impossible to
> change a single line of code. Careful compromises are needed to have
> the log4j project evolve.
>
>> Nothing has been new in this thread.
>
> Yes. From the start it was clear that you were never going to change
> your mind. Even when there were strictly *zero* backward compatibility
> issues, you voiced strong opposition to adopting the SLF4J API or UGLI
> as it was formerly called. I am hoping that the other log4j committers
> will eventually realize that your stewardship of log4j, both in style
> and substance, have been detrimental to the project. We might have
> reached that point today, which would be something new in this
> thread.
>
> I would also like to remind you that the position of chairperson
> should be the subject of new elections from time to time. You have
> been chairperson for Apache Logging for 4 years without organizing new
> elections.
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message