Curt Arnold wrote:
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.
A direct implementation of log4j would be beneficial to users calling
the SLF4J API with log4j as the underlying implementation. Nothing
earth shaking but still moderately beneficial. Although adoption of
SLF4J will break clients passing objects as the message parameter,
such usage is very limited. So clients wishing to migrate to the new
API can do so very quickly. Binary compatibility for clients invoking
org.apache.log4j.Logger can be maintained by implementing the SLF4J in
a different package. Thus, clients could replace log4j 1.2.x jar with
log4j 1.4.jar without being affected. New code can refer to SLF4J API
and legacy code can continue to refer to org.apache.log4j.
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.
Look Curt, SLF4J does not need ASF's endorsement. The project is doing
well as it is. By the way, I resent the implication. Moreover, if you
believe that java.util.logging has already won the API standardization
war years ago, what are you doing working on log4j?
I believe that we would render the java community a valuable service
by converging on a popular and well-established logging API. In 2004
one could have reasonably argued that the SLF4J API was not stable or
unsuitable, that is no longer the case today. Curt, I don't expect you
to jump up and down with joy about my proposal. However, I hope you
can see the bigger picture, especially since we can preserve
compatibility for existing clients.
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 motivation here is to converge, not to create yet another implementation.
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.
If we can reach a decision, it can be done in days. The hard part is
reaching a decision.
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.
The point here is not comparing implementations but to have API
convergence. It is less a technical matter (there not an ounce of
doubt that it can be done with good results) than a question of
collective will of log4j committers and log4j users.
Curt has plainly expressed his feelings. What do others think?
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
