logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Release of log4j version 1.2.10
Date Sat, 30 Apr 2005 06:23:43 GMT

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: 
RCS file: 
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: 
retrieving revision
retrieving revision
diff -r1.68.2.5 -r1.68.2.6
 > import org.slf4j.impl.MessageFormatter;

 >   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) {


 >   public boolean isWarnEnabled() {

 >   public boolean isErrorEnabled() {


 >   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: 
retrieving revision
retrieving revision
diff -r1.16.2.1 -r1.16.2.2
 > import org.slf4j.ULogger;
< 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 

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 

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 

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message