On Apr 29, 2005, at 1:13 PM, Ceki Gülcü wrote:
Log4j developers are proud to announce the availability of log4j version 1.2.10. This version adds native support for SLF4J, along with a minor bug fix. The Simple Logging Facade for Java or (SLF4J) is intended to serve as a simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time. For more details about SLF4J, see
I reviewed the changes between v1_2_9 and the v1_2-branch (I didn't find a label for v1_2_10) using:
cvs -z3 diff -r v1_2_9 -r v1_2-branch
And I couldn't find the minor bug fix unless it was in the documentation. The following files were changed:
RCS file: /home/cvs/logging-log4j/build.xml,v
RCS file: /home/cvs/logging-log4j/docs/Attic/FAQ.html,v
RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
RCS file: /home/cvs/logging-log4j/src/xdocs/Attic/contactUs.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/contributors.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/documentation.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/download.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/earlier.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/history.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/index.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/plan.xml,v
RCS file: /home/cvs/logging-log4j/src/xdocs/stylesheets/project.xml,v
The significant changes appear to be (sections omitted):
Index: src/java/org/apache/log4j/Category.java
===================================================================
RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v
retrieving revision 1.68.2.5
retrieving revision 1.68.2.6
diff -r1.68.2.5 -r1.68.2.6
33a34
> import org.slf4j.impl.MessageFormatter;
251a253,306
> public void debug(Object messagePattern, Object arg) {> public void debug(String messagePattern, Object arg1, Object arg2) {> public void error(Object messagePattern, Object arg) {> public void error(String messagePattern, Object arg1, Object arg2) {> public void info(Object messagePattern, Object arg) {> public void info(String messagePattern, Object arg1, Object arg2) {755a921,947
> public boolean isWarnEnabled() {> public boolean isErrorEnabled() {1001a1194,1247
> public void warn(Object messagePattern, Object arg) {> public void warn(String messagePattern, Object arg1, Object arg2) {Index: src/java/org/apache/log4j/Logger.java
===================================================================
RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v
retrieving revision 1.16.2.1
retrieving revision 1.16.2.2
diff -r1.16.2.1 -r1.16.2.2
10a11
> import org.slf4j.ULogger;
20c21
< public class Logger extends Category {
---
> public class Logger extends Category implements ULogger {
I reviewed the slf4j.org web site and there is a release labeled slf4j-1.0-beta1 and user and dev mailing lists with no logged messages. My understanding of the motivation to spin UGLI out of ASF was so that interested parties would have an neutral site where to resolve all the thorny issues that have been encountered with previous approaches at a common logging API. However by incorporating this particular version of SLF4J into a production release of log4j, that greatly limits the freedom of the SLF4J community to make changes or additions to the interfaces (or conversely places a production version of log4j at their whims). For example, if a new method is added to ULogger, calling code will receive a MethodNotFound exception when running against log4j 1.2.10.
I understand the desire to eliminate the facade-tax by making log4j directly implement ULogger and maybe there will be enough consensus around SLF4J by the time log4j 1.3 is production ready that there will be acceptable. However as SLF4J as an entity is only weeks old and appears to have zero-community at this point, it seems totally inappropriate to add it as a dependency for the 10th release of log4j 1.2.
Even if SLF4J becomes generally accepted, my preference would for it still to be a facade over log4j. But there may be ways to almost eliminate the facade-tax. If the message satisfies the threshold of the logger or hierarchy and is likely to be logged, the additional function call from the facade to the implementation should not be significant. The crucial issue is to make the evaluation of that initial screen to be as fast as possible. If the facade has enough information to make that determination without delegating to the underlying implementation, there performance between an directly implemented SLF4J and a facade should be very hard to detect. To do that in an environment where the configuration may be changing, that would require mechanisms for the facade to register its interest in configuration changes however that could be done to support slf4j without adding any slf4j dependencies to log4j. If you want to support that approach, you may want to add another versions of org.slf4j.LoggerFactory.getLogger that takes a boolean parameter indicating whether the logger should monitor threshold changes. If false, then the implementation would be free to get the level of the logger on the first call and cache that value, and if the parameter was true the implementation could monitor the level on implementations that support it (log4j 1.3) or always delegate to the underlying implementation.
At this point, I think the best thing to do is pull 1.2.10 and pretend it never existed. As far as I can tell there are no bug fixes in 1.2.9 except possibly in the documentation and I don't think doc changes would be sufficient to justify another release.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
