Jacob Kjome wrote:
> Ceki Gulcu wrote:
>> It should not be difficult to write a SLF4J binding for log4j which
>> supports repository selectors.
>>
> ...which would require Log4j to directly implement the SLF4J interfaces, no?
> Doubtful for 1.2.xx.
If there is support for this idea, it can be implemented with relative
ease. The log4j version can be called 1.3, 1.4 or even 2.0. The
difficult part is reaching agreement among the log4j committers. I
think if log4j implemented SLF4J, this would have a very positive
unifying effect on logging in the Java world. Obviously, I am willing
to do the work.
As you are probably aware, more and more projects are adopting the
SLF4J API. I would venture say that SLF4J's adoption rate is roughly
equivalent to that of log4j itself.
Recently, Jspwiki decided to adopt the SLF4J API for its logging. See
https://issues.apache.org/jira/browse/JSPWIKI-376
Harry Metske synthesized various logging paths in JSPWiki
https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp
I was taken aback by the picture he paints. I think we owe it to
Java developers to propose a saner logging model.
Obviously, the adoption of the SLF4J API by log4j will be break 100%
compatibility. More precisely, logging statements passing objects as
messages will need to be converted to strings. Given that there are
comparatively very few log statements using Object instead of String,
in my experience, it takes half an hour to convert even the largest
projects.
The choice is between preserving 100% compatibility but force projects
to deal with several logging libraries or to break 100% compatibility
for but offer a saner and more unified model.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
