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: [email protected]
For additional commands, e-mail: [email protected]
