Here is a brain dump, in the form of a QA list, in response to Jake's last
message and the questions raised by him.
Q: What is the impetus to modify log4j, or what is to be gained by
log4j directly implementing SLF4J?
A: The gain is standardization. When projects debate about which
logging API they should use, while often times they decide upon SLF4J,
it just takes too much effort and time to reach that conclusion. It is
just a big waste of time for everyone involved.
So the question is not "what is in it for log4j, but what is in it for
the wider java developer community".
Q: Wouldn't implementing the SLF4J API create an undesirable coupling
between SLF4J and log4j?
Yes, log4j will be expected to follow the SLF4J API. This indeed
creates a coupling. However, given that the SLF4J API is very stable,
the effects on log4j are likely to be manageable. Moreover, the
logback project which natively implements the SLF4J API keeps up with
SLF4J without any difficulty. The SLF4J FAQ has a related entry:
http://www.slf4j.org/faq.html#version_checks
Q: What is manageable ease?
A: Log4j version implementing in the SLF4J API, assuming it
participates in SLF4J's version check mechanism, would need to set the
SLF4J version against which it (log4j) was complied in a variable called
REQUESTED_API_VERSION. This should not involve a few minutes of work
every now and then.
Q: But I don't have a few minutes. Would you do it?
A: Yes, I would.
Q: Should SLF4J be integrated into log4j 1.4 or 2.0?
A: Given that 2.0 aims at a wider leap, 1.4 seems an easier target,
especially one that can be arrived at within a reasonably short time
frame. (In the remainder of the text, the SLF4J version of log4j will
be called 1.4.)
Q: Wouldn't implementing the SLF4J API break compatibility?
A: Log4j could retain the existing signatures for the
org.apache.log4j.Category/Logger classes. These classes would delegate
their work to an instance of the org.apache.log4j.impl.Logger class
which would be a native implementation of the org.slf4j.Logger
interface. This approach would allow for existing client code to be
compatible with log4j 1.4. (They would just need to replace
log4j-1.2.x.jar with log4j-1.4.jar.
Q: Wouldn't migrating to log4j 1.4 entail the inclusion of an
additional jar?
A: Yes, in addition to log4j-1.4.jar, clients would need to add
slf4j-api.jar on their class path?
Q: Are there other modifications required in log4j?
A: No other modifications would be required in the log4j code
base. However, the log4j documentation would need to be modified to
refer to org.slf4j.Logger instead of org.apache.log4j.Logger.
Q: What is the advantage for log4j users?
A: Users of log4j 1.4, assuming they do not refer to the log4j API
directly but to SLF4J instead, could switch to another logging
framework such as j.u.l. or logback by simply replacing log4j-1.4.jar
with another jar. However, issues related to logging configuration are
not covered by the SLF4J API. Users would need to resort to ad hoc
methods to migrate their configuration files.
Q: Why not just use j.u.l?
A: Despite the fact that jul is included in the JDK, it has not gained
wide acceptance. Most java projects either use log4j, commons-logging
or SLF4J as their logging API.
Q: Considering a software project as a whole, isn't logging a secondary
concern?
A: Absolutely. Hence, this proposal, intended to make life easier for
software developers, albeit a little harder on log4j developers.
Q: What is in it for the log4j project?
A: Besides helping fellow developers, when projects decide upon a
logging API, log4j will be the logical candidate.
Q: Isn't log4j the logical candidate already?
A: Yes, it often is.
Q: So, isn't doing nothing the easiest and smartest approach?
A: Sigh. It usually is.
Q: Why aren't you following your own advice?
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
