The discussion between Curt Arnold, Jacob Kjome and Ceki Gulcu tells me
there is more to this than meets the eye, especially when it comes to
the political side of it.
Going back to the technical side, and the original proposal:
>>Ceki Gulcu writes:
>>"Unfortunately, the adoption of the SLF4J API by log4j will be break
100% compatibility with existing log4j >>clients."
The motivation for breaking 100% compatibility should be rather strong,
given the widespread use of log4j.
Having to go through the whole codebase and doing manual modifications,
or even worse, automatic migration changes, is a risk, and time
consuming. Maybe not so much on the code change itself, but on
regression testing!
The changes needs to be done on every logging statement using an object,
*)log.debug(object)->log.debug(object.toString())
*)log.fatal("") needs to be modified to log.error("");
*)NDC statements must be migrated to MDC
*)...
>>Ceki Gulcu writes:
>>"even very large projects can be migrated to the SLF4J API within
half an hour"
from sl4j.org:
"Suppose that your CRM application uses log4j for its logging. However,
one of your important clients request that logging be performed through
JDK 1.4 logging. If your application is riddled with thousands of direct
log4j calls, migration to JDK 1.4 would be a long and error-prone process."
So why is it that moving from log4j -> to jdk 1.4 would be a long and
error-prone process
but going from log4j -> sl4j is smoother than a baby's bottom?
I might go for sl4j in next project, and then using the log4j-over-sl4j
bridge.
Thus the log4j-development can be spent on improving the
appenders/configurators and backend part, instead of spending time on
sl4j-migration.
But please, maintain 100% compatibility in log4j!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
