logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Release of log4j version 1.2.10
Date Mon, 02 May 2005 18:41:29 GMT


I guess you involuntarily  missed the HISTORY.txt file.

http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/docs/HISTORY.txt?rev=1.27.2.1&view=markup

http://issues.apache.org/bugzilla/show_bug.cgi?id=34491

At 08:23 4/30/2005, Curt Arnold wrote:

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

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message