logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <c...@qos.ch>
Subject Re: will there be a parameterized message in log4j like it is in slf4j?
Date Mon, 05 Oct 2009 10:39:47 GMT
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, but in return will help consolidate
Java logging, something which is sorely needed. It can be argued that
SLF4J is an externally run project or that it is not directly in
log4j's interest to implement SLF4J directly, in the mean time, log4j
is becoming increasingly irrelevant as it vegetates.

Your offer to review any patch or branch subject to your own personal
criteria of backward compatibility is not exactly new nor alluring. As
I see it, as in the past, you will keep coming up with reasons to
stall the project. Fortunately, with sufficient support from the other
log4j committees, your approval can be dispensed with.

Curt Arnold wrote:
> 
> On Oct 4, 2009, at 1:53 PM, Jess Holle wrote:
> 
>>
>>> Code using using org.apache.log4j.Logger would continue to work as 
>>> is, ensuring backward compatibility, at least as far as the log4j 
>>> signatures are concerned. Users who rely on the fact that the message 
>>> argument was an Object instead of String would need to modify few 
>>> lines of code. In the worst case, this change could cause loss of 
>>> logging information but would NOT cause compile-time problems or 
>>> issues related to method signatures.
>> This is a key ability in log4j, which I for one leverage to pass 
>> complex, structured data to specialized loggers, e.g. to dissect these 
>> structures and place various fields into separate relational database 
>> columns.
>>
>> Losing first class access to such abilities is a non-starter.
>>
> 
> The whole ObjectRenderer facility in log4j requires the ability to pass 
> Object's as the first parameter.  Anyone who used facility in the way 
> that it was intended to be used would be broken if the first parameter 
> was restricted to be only being a String.  It may be okay to break some 
> app that depended on an undocumented feature or used a feature in some 
> way that was not intended, but removing an established facility in our 
> documented public API being used the way that it was intended in a minor 
> release without any deprecation cycle is a betrayal of trust.  First 
> priority in a minor release should be to do no harm, adding a new 
> feature or even reinvigorating the project should not trump that.
> 
> I'd be willing to review any patch or branch that might be able to 
> reconcile SLF4J and log4j without breaking compatibility, but every time 
> I've tried I've run into unsurmountable obstacles.  If it is easy and 
> I've missed something in my attempts, I'm be happy to see the code that 
> shows that I missed something.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 

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


Mime
View raw message