On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote:
Hello,
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. Although the SLF4J API is not
perfect, most SLF4J users seem to be extremely happy with it.
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 as log4j
committers owe it to Java developers to propose a saner logging model.
Given the multiplicity of logging APIs in the Java world, I propose
that log4j implement the SLF4J API directly. This can be done in the
next version of log4j, say 1.3 or 2.0.
Unfortunately, the adoption of the SLF4J API by log4j will be break
100% compatibility with existing log4j clients. More precisely,
logging statements passing java.lang.Object as the message parameter
will need to be changed to java.lang.String. Assuming that the
proportion of logging statements using objects instead string is
extremely small, comparatively few users will be affected. More
importantly, in my experience, even very large projects can be
migrated to the SLF4J API within half an hour.
There is even a tool called slf4j-migrator to help with such
migration [1].
Is there support for my proposal?
[1] http://www.slf4j.org/migrator.html
--
Ceki Gülcü
I've logged this issue as https://issues.apache.org/jira/browse/LOG4J2-27
and Scott's desire for increased support for properties as https://issues.apache.org/jira/browse/LOG4J2-28
. I've attached a PDF version of the referenced OpenOffice file to
LOG4J2-27.
If the proposal is that direct support for SLF4J be considered as a
potential feature of log4j 2.0 as previously described on this list (a
designed for Java 5 replacement for log4j 1.x with fine grained
concurrency), then LOG4J2-27 captures that potential feature for
consideration at the proper time.
If the proposal is to create a branch of the log4j 1.2 code base that
directly implements SLF4J, that is a different matter. I could
recount all sorts of previous discussions on the issues involved, but
I don't want to do that if that is not the proposal.
On Dec 3, 2008, at 7:18 PM, Ralph Goers wrote:
I would support this in 2.0. Work has yet to start on that though. I
=20
don't see how 100% compatibility can be maintained anyway as the
plan, =20=
as I understand it, includes moving to a later minimum Java release
=20
and removing deprecated classes.
The questions I wonder about are:
1. It would be easier if the author of Logback :-) was willing to =20
donate it to Apache as the basis for Log4j 2.0.
2. Would the community be willing to accept it since it has major =20
differences with Log4j.
Ralph
logback would have to go through the Incubator PMC like any externally
developed code base. Given the history and the license differences, I
have intentionally not examined logback and can make no statement as
its desirability as a basis for a designed for Java 5 log4j.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
