On Dec 4, 2008, at 6:26 AM, Ceki Gulcu wrote:
Hello Ralph,
Thank for you for your reply. Logback as the basis for log4j 2.0 is a
larger step than what I had in mind. Implementation of the SLF4J API
directly in log4j is a low-hanging fruit but having a significant
positive impact on the java community, by virtue of de facto
standardization.
IMHO, breaking 100% compatibility would be a reasonable price to pay
given the benefits involved, namely convergence into a logging
standard.
As far as I can tell, there is no significant practical advantage to
our user community to do a direct implementation of SLF4J in log4j
over the facade implementation provided by slf4j.org. I have never
seen a significant performance difference between the two approaches
and a direct implementation has several strong negatives to the log4j
community and users that have been previously discussed.
However, I could see a significant political advantage to SLF4J to
have an implicit endorsement from the ASF and in my mind that is what
this proposal is about. In my mind, java.util.logging has already won
the API standardization war years ago, but it has been mostly limited
the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5
) for log4j 2.0 is to have the back-end classes independent of the
API, so that the bulk of log4j 2 is isolated from the client's API
choice.
SLF4J is a very stable API which has not changed incompatibly since
version 1.0-beta5, released on August 2005. Client code compiled
against SLF4J 1.0-beta5 will compile against any subsequent
version. Client code compiled against SLF4J 1.0-beta5 will run with
any subsequent version (runtime/binary compatibility).
If we can reach an agreement, SLF4J-compliant log4j can be released
within *days*. It can be named log4j 1.4 or log4j 2.0. If it were
named
1.4, that version could form the base for log4j 2.0.
I will respond to Scott's message separately.
With the breaking API change, it should not be called Apache log4j 1.4
and should not use the org.apache.log4j package names for the modified
classes. Back when SLF4J spun out from the ASF, SLF4J.org or QoS.ch
provided a log4j variant called nlog4j which is no longer available.
If this has to come to pass, I'd much rather see an Apache nlog4j or
slog4j than confuse the Apache log4j brand.
The Apache process makes it difficult enough get non-controversial
maintenance releases out in days, let alone something with as much
potential for disruption as this.
I haven't been able to contribute much code since Hurricane Ike, but I
just returned from a long Thanksgiving trip and was expecting to work
on getting a log4j 1.2.16 release candidate ready. However, I'll
explore setting up an experimental take on a direct implementation of
SLF4J without doing violence to Java compatibility expectations, so
that a side-by-side comparison of a direct and facade implementation
could be made.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
