Contact us

The format of the log output can be easily changed by extending the Layout @@ -444,7 +445,7 @@

The open and collaborative way in which log4j is developped ensures that it continues to preserve and even widen its - competitive edge. At some point, input from bright developpers + competitive edge. At some point, input from bright developers from all over the world is bound to make a difference.

Better alternative based on message patterns

As of log4j version 1.3, there exists a significantly more - convenient alternative based on message patterns. Assuming - entry is an object, you can write: -

After evaluting whether to log or not, and only if the - decision is positive, will the logger instace format the - message and replace the '{}' pair with the string value of - entry. In other words, the paramerized form does - not incur the cost of parameter construction in case the log - statement is disabled. -

Thus, the following two lines will yield the exact same - output. However, the second form will perform at least 30 - (thirty) times faster in case of a disabled logging - statement. -

- l.debug("The new entry is "+entry+".");
- l.debug("The new entry is {}.", entry); -

2.4 Are there any suggested ways for naming loggers? @@ -1079,7 +1042,7 @@ appear in the file /docs/faq.html.

- + 1.27.2.2 +8 -12 logging-log4j/docs/HISTORY.txt Index: HISTORY.txt =================================================================== RCS file: /home/cvs/logging-log4j/docs/HISTORY.txt,v retrieving revision 1.27.2.1 retrieving revision 1.27.2.2 diff -u -r1.27.2.1 -r1.27.2.2 --- HISTORY.txt 29 Apr 2005 17:07:43 -0000 1.27.2.1 +++ HISTORY.txt 6 May 2005 05:32:35 -0000 1.27.2.2 @@ -5,23 +5,19 @@ client code. [***] Changes requiring important modifications to existing client code. + Current cvs v1_2-branch (1.2.11 prerelease) + - Fixed bug #34491 whereby the class o.a.log4j.or.jms.MessageRenderer + would not be compiled in the build.jms target. Bug reported by Andy + McBride. http://issues.apache.org/bugzilla/show_bug.cgi?id=34491 + April 28th, 2005 - Release of version 1.2.10 - - Added support for the SLF4J project. The Logger class now - implements the ULogger interface defined by the SLF4J. See - - http://www.slf4j.org - - for more detailed information. - - - Fixed bug #34491 whereby the class o.a.log4j.or.jms.MessageRenderer - would not be compiled in the build.jms target. Bug reported by Andy - McBride. - - http://issues.apache.org/bugzilla/show_bug.cgi?id=34491 + - Version 1.2.10 was not following the accepted rules and process of the + log4j project and Logging Services Project and was recalled and removed. + Please do not use version 1.2.10. November 1st, 2004 No revision No revision 1.68.2.7 +0 -246 logging-log4j/src/java/org/apache/log4j/Category.java Index: Category.java =================================================================== RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Category.java,v retrieving revision 1.68.2.6 retrieving revision 1.68.2.7 diff -u -r1.68.2.6 -r1.68.2.7 --- Category.java 28 Apr 2005 20:34:04 -0000 1.68.2.6 +++ Category.java 6 May 2005 05:32:36 -0000 1.68.2.7 @@ -31,7 +31,6 @@ import java.util.MissingResourceException; import java.util.ResourceBundle; -import org.slf4j.impl.MessageFormatter; /** * This class has been deprecated and @@ -250,60 +249,6 @@ } } - /** - * Log a message with the DEBUG level with message formatting - * done according to the value of messagePattern and - * arg parameters. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg The argument to replace the formatting element, i,e, - * the '{}' pair within messagePattern. - * @since 1.2.10 - */ - public void debug(Object messagePattern, Object arg) { - if (repository.isDisabled(Level.DEBUG_INT)) { - return; - } - - if (Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel())) { - if (messagePattern instanceof String){ - String msgStr = (String) messagePattern; - msgStr = MessageFormatter.format(msgStr, arg); - forcedLog(FQCN, Level.DEBUG, msgStr, null); - } else { - // To be failsafe, we handle the case where 'messagePattern' is not - // a String. Unless the user makes a mistake, this should never happen. - forcedLog(FQCN, Level.DEBUG, messagePattern, null); - } - } - } - - /** - * Log a message with the DEBUG level with message formatting - * done according to the messagePattern and the arguments arg1 and arg2. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg1 The first argument to replace the first formatting element - * @param arg2 The second argument to replace the second formatting element - * @since 1.2.10 - */ - public void debug(String messagePattern, Object arg1, Object arg2) { - if (repository.isDisabled(Level.DEBUG_INT)) { - return; - } - if (Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel())) { - messagePattern = MessageFormatter.format(messagePattern, arg1, arg2); - forcedLog(FQCN, Level.DEBUG, messagePattern, null); - } - } /** Log a message object with the DEBUG level including @@ -348,62 +293,6 @@ forcedLog(FQCN, Level.ERROR, message, null); } - -/** - * Log a message with the ERROR level with message formatting - * done according to the value of messagePattern and - * arg parameters. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg The argument to replace the formatting element, i,e, - * the '{}' pair within messagePattern. - * @since 1.2.10 - */ - public void error(Object messagePattern, Object arg) { - if (repository.isDisabled(Level.ERROR_INT)) { - return; - } - - if (Level.ERROR.isGreaterOrEqual(this.getEffectiveLevel())) { - if (messagePattern instanceof String){ - String msgStr = (String) messagePattern; - msgStr = MessageFormatter.format(msgStr, arg); - forcedLog(FQCN, Level.ERROR, msgStr, null); - } else { - // To be failsafe, we handle the case where 'messagePattern' is not - // a String. Unless the user makes a mistake, this should never happen. - forcedLog(FQCN, Level.ERROR, messagePattern, null); - } - } - } - - /** - * Log a message with the ERROR level with message formatting - * done according to the messagePattern and the arguments arg1 and arg2. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg1 The first argument to replace the first formatting element - * @param arg2 The second argument to replace the second formatting element - * @since 1.2.10 - */ - public void error(String messagePattern, Object arg1, Object arg2) { - if (repository.isDisabled(Level.ERROR_INT)) { - return; - } - if (Level.ERROR.isGreaterOrEqual(this.getEffectiveLevel())) { - messagePattern = MessageFormatter.format(messagePattern, arg1, arg2); - forcedLog(FQCN, Level.ERROR, messagePattern, null); - } - } - /** Log a message object with the ERROR level including the stack trace of the {@link Throwable} t passed as @@ -766,60 +655,6 @@ } /** - * Log a message with the INFO level with message formatting - * done according to the value of messagePattern and - * arg parameters. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg The argument to replace the formatting element, i,e, - * the '{}' pair within messagePattern. - * @since 1.2.10 - */ - public void info(Object messagePattern, Object arg) { - if (repository.isDisabled(Level.INFO_INT)) { - return; - } - - if (Level.INFO.isGreaterOrEqual(this.getEffectiveLevel())) { - if (messagePattern instanceof String){ - String msgStr = (String) messagePattern; - msgStr = MessageFormatter.format(msgStr, arg); - forcedLog(FQCN, Level.INFO, msgStr, null); - } else { - // To be failsafe, we handle the case where 'messagePattern' is not - // a String. Unless the user makes a mistake, this should never happen. - forcedLog(FQCN, Level.INFO, messagePattern, null); - } - } - } - - /** - * Log a message with the INFO level with message formatting - * done according to the messagePattern and the arguments arg1 and arg2. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg1 The first argument to replace the first formatting element - * @param arg2 The second argument to replace the second formatting element - * @since 1.2.10 - */ - public void info(String messagePattern, Object arg1, Object arg2) { - if (repository.isDisabled(Level.INFO_INT)) { - return; - } - if (Level.INFO.isGreaterOrEqual(this.getEffectiveLevel())) { - messagePattern = MessageFormatter.format(messagePattern, arg1, arg2); - forcedLog(FQCN, Level.INFO, messagePattern, null); - } - } - /** Log a message object with the INFO level including the stack trace of the {@link Throwable} t passed as parameter. @@ -918,33 +753,6 @@ return Level.INFO.isGreaterOrEqual(this.getEffectiveLevel()); } - /** - Check whether this category is enabled for the info Level. - See also {@link #isDebugEnabled}. - - @return boolean - true if this category is enabled - for level WARN, false otherwise. - @since 1.2.10 - */ - public boolean isWarnEnabled() { - if(repository.isDisabled(Level.WARN_INT)) - return false; - return Level.WARN.isGreaterOrEqual(this.getEffectiveLevel()); - } - - /** - Check whether this category is enabled for the info Level. - See also {@link #isDebugEnabled}. - - @return boolean - true if this category is enabled - for level ERROR, false otherwise. - @since 1.2.10 - */ - public boolean isErrorEnabled() { - if(repository.isDisabled(Level.ERROR_INT)) - return false; - return Level.ERROR.isGreaterOrEqual(this.getEffectiveLevel()); - } /** Log a localized message. The user supplied parameter @@ -1191,60 +999,6 @@ forcedLog(FQCN, Level.WARN, message, null); } - /** - * Log a message with the WARN level with message formatting - * done according to the value of messagePattern and - * arg parameters. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg The argument to replace the formatting element, i,e, - * the '{}' pair within messagePattern. - * @since 1.2.10 - */ - public void warn(Object messagePattern, Object arg) { - if (repository.isDisabled(Level.WARN_INT)) { - return; - } - - if (Level.WARN.isGreaterOrEqual(this.getEffectiveLevel())) { - if (messagePattern instanceof String){ - String msgStr = (String) messagePattern; - msgStr = MessageFormatter.format(msgStr, arg); - forcedLog(FQCN, Level.WARN, msgStr, null); - } else { - // To be failsafe, we handle the case where 'messagePattern' is not - // a String. Unless the user makes a mistake, this should never happen. - forcedLog(FQCN, Level.WARN, messagePattern, null); - } - } - } - /** - * Log a message with the WARN level with message formatting - * done according to the messagePattern and the arguments arg1 and arg2. - *
- * This form avoids superflous parameter construction. Whenever possible, - * you should use this form instead of constructing the message parameter - * using string concatenation. - * - * @param messagePattern The message pattern which will be parsed and formatted - * @param arg1 The first argument to replace the first formatting element - * @param arg2 The second argument to replace the second formatting element - * @since 1.2.10 - */ - public void warn(String messagePattern, Object arg1, Object arg2) { - if (repository.isDisabled(Level.WARN_INT)) { - return; - } - if (Level.WARN.isGreaterOrEqual(this.getEffectiveLevel())) { - messagePattern = MessageFormatter.format(messagePattern, arg1, arg2); - forcedLog(FQCN, Level.WARN, messagePattern, null); - } - } - /** Log a message with the WARN level including the stack trace of the {@link Throwable} t passed as 1.16.2.3 +1 -2 logging-log4j/src/java/org/apache/log4j/Logger.java Index: Logger.java =================================================================== RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Logger.java,v retrieving revision 1.16.2.2 retrieving revision 1.16.2.3 diff -u -r1.16.2.2 -r1.16.2.3 --- Logger.java 28 Apr 2005 20:34:04 -0000 1.16.2.2 +++ Logger.java 6 May 2005 05:32:36 -0000 1.16.2.3 @@ -8,7 +8,6 @@ package org.apache.log4j; import org.apache.log4j.spi.LoggerFactory; -import org.slf4j.ULogger; /** @@ -18,7 +17,7 @@ @since log4j 1.2 @author Ceki Gülcü */ -public class Logger extends Category implements ULogger { +public class Logger extends Category { /** The fully qualified name of the Level class. See also the No revision No revision 1.14.2.1 +9 -14 logging-log4j/src/xdocs/Attic/contactUs.xml Index: contactUs.xml =================================================================== RCS file: /home/cvs/logging-log4j/src/xdocs/Attic/contactUs.xml,v retrieving revision 1.14 retrieving revision 1.14.2.1 diff -u -r1.14 -r1.14.2.1 --- contactUs.xml 9 May 2002 15:43:44 -0000 1.14 +++ contactUs.xml 6 May 2005 05:32:36 -0000 1.14.2.1 @@ -2,7 +2,7 @@ - Ceki Gulcu + Ceki Gulcu Contact us @@ -14,21 +14,16 @@
Discussion on log4j and logging in general are held on the log4j-user mailing list. To subscribe to this list send an e-mail to log4j-user-subscribe@jakarta.apache.org. + HREF="mailto:log4j-user-subscribe@logging.apache.org">log4j-user-subscribe@logging.apache.org.

Development related discussions are held on the log4j-dev mailing list. To subscribe to this list send an e-mail to log4j-dev-subscribe@jakarta.apache.org.
- -
All developers are encouraged to subscribe to the - log4j-cvs list which will notify the subscribers of - CVS any commits to the repository. To subscribe to this list - send an e-mail to log4j-cvs-subscribe@jakarta.apache.org. - Committers should subscribe to this list with their - Apache e-mail address. + HREF="mailto:log4j-dev-subscribe@logging.apache.org">log4j-dev-subscribe@logging.apache.org. All + developers are encouraged to subscribe to the + log4j-dev list which will notify the subscribers of + any commits to our CVS repository.

To prevent spam, we expect you to be subscribed to a list @@ -37,7 +32,7 @@ creates needless work for us.
-
Most Jakarta mailing lists, in particular the log4j mailing +
Most Logging Services mailing lists, in particular the log4j mailing lists, are archived. Some of the known archives are listed below:
@@ -48,9 +43,9 @@ http://www.mail-archive.com

Label	Ceki	design board	Significantly progressed
?	vaporware
Plugins/Receivers	+ A Plugin framework has been designed and implemented. + All of the currently developed plugins are "Receivers", which can be thought of as the reverse of an appender; something + that accepts LoggingEvents from some external source. + + This has proven particulaly useful with the log4j ports, with the addition of the XML-based Receivers able to accept + LoggingEvents generated from other languages (see "Overture to other programming languages" below) + + +	All	Significantly progressed
Improvements to Chainsaw	- Visualisation and dynamic filtering of logging event is - bound to be a very important area of activity in the - future. A number of important improvements to chainsaw - have been suggested. + Chainsaw v2 development has now progressed to the point where the main developers of it + and many other members of the logging community are using it daily. It's still pre-alpha but only + because we keep thinking up things to add.	Oliver Burn	under discusison	Scott Deboy and Paul Smith	Significantly progressed
?	not started	Ceki	Completed, still testing
Overture to other programming languages	It is higly desriable to allow log4j ports in other languages - to access log4j services in a language independent way. -	It is higly desriable to allow log4j ports in other languages + to access log4j services in a language independent way. + + The use of a standard XML format to represent a LoggingEvent has been established and many of the related logging projects from + non-Java languages have begun to support it. In fact, a number of the log4j ports have volunteered to join Apache! + + Scott Deboy has completed work to create a fex XML-based Receiver + classes that can accept logging events from an external source, and 'import' them into the local log4j environment.	?	not started	Ceki, Scott Deboy	Significantly Progressed (if not completed)
Kevin Steppe	not started	Ceki	Significantly Progressed

Label

Ceki

design board

Significantly progressed

vaporware

Plugins/Receivers

A Plugin framework has been designed and implemented.

All of the currently developed plugins are "Receivers", which can be thought of as the reverse of an appender; something + that accepts LoggingEvents from some external source. +

This has proven particulaly useful with the log4j ports, with the addition of the XML-based Receivers able to accept + LoggingEvents generated from other languages (see "Overture to other programming languages" below) +

+ +

All

Significantly progressed

Improvements to Chainsaw

Visualisation and dynamic filtering of logging event is - bound to be a very important area of activity in the - future. A number of important improvements to chainsaw - have been suggested. +

Chainsaw v2 development has now progressed to the point where the main developers of it + and many other members of the logging community are using it daily. It's still pre-alpha but only + because we keep thinking up things to add.

Oliver Burn

under discusison

Scott Deboy and Paul Smith

Significantly progressed

not started

Ceki

Completed, still testing

Overture to other programming languages

It is higly desriable to allow log4j ports in other languages - to access log4j services in a language independent way. -

It is higly desriable to allow log4j ports in other languages + to access log4j services in a language independent way.

+ +

The use of a standard XML format to represent a LoggingEvent has been established and many of the related logging projects from + non-Java languages have begun to support it. In fact, a number of the log4j ports have volunteered to join Apache!

+ +

Scott Deboy has completed work to create a fex XML-based Receiver + classes that can accept logging events from an external source, and 'import' them into the local log4j environment.

not started

Ceki, Scott Deboy

Significantly Progressed (if not completed)

Kevin Steppe

not started

Ceki

Significantly Progressed

Label	Comment	Volunteer	Status
More test cases	We need more automated test cases to catch bugs as early - is possible.It is highly recommended to add a new test case - with each new feature or component.	All committers	ongoing effort
Removal of deprecated methods	Deprecated `setOption` and `getOption` - methods in appender and layouts should be removed.	Ceki	done
JDBCAppender	- We currently have two competing JDBCAppenders: one by - Thomas Fenner and the other by Kevin Steppe. - - Kevin Steppe stood up and did it. -	Kevin Steppe	done
Log4j in applets	In order to minimize network traffic, the size of log4j-core.jar - needs to be reduced to at most 50KB. - - Log4jME has been released. It's less than 20KB. -	Ceki	done
Improved documentation	Log4j documentation needs to be enhanced with configuration - examples and much more hand-holding.	Ceki	ongoing effort
Mapped Diagnostic Contexts	Mapped Diagnostic Contexts are similar to the NDC - except that the MDC is a string to string map instead of - a stack that the user sets when entering a special - context. The `PatternLayout` has to be - enhanced to support this by extending the %x pattern to - accept an argument. Here is an example: - - - ConversionPattern=3D%d %p %c %x{server} %x{host} - %m%n - - - User code: - - { - MDC.put("server", "totoServer"); - MDC.put("host", "someHost"); - - logger.debug("Hello"); - - } - - will print: - 2000-01-24 10:00:00,000 DEBUG totoServer someHost - Hello - - To make MDCs truly user friendly - `ThreadLocal` variables are required. This - will allow the MDC to be inherited by child - threads. `ThreadLocal` are only supported - under JDK 1.2 and above. In JDK 1.1, the MDC will not - work but won't harm the user application either. -	Ceki	done
Enhanced variable substitution support in DOMConfigurator		Ceki	done
FallbackErrorHandler	The FallbackErrorHandler implements the ErrorHandler - interface such that a secondary appender may be - specified. This secondary appender takes over if the primary - appender fails for whatever reason. - - The DOMConfigurator needs to be extended to support the - FallbackErrorHandler - -	Ceki	implemented, requires further testing
Ensure backward compatibility of LoggingEvent - objects	To avoid deployment problems we must ensure that - LoggingEvent objects are compatible between 1.2 and 1.1.3. - - Robert Bushman has proposed a very innovative way for - solving this problem. See - http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01397.html - for further details. - -	Ceki	implemented, manually tested, requires automated test cases

Label

Comment

Volunteer

Status

More test cases

We need more automated test cases to catch bugs as early - is possible.It is highly recommended to add a new test case - with each new feature or component.

All committers

ongoing effort

Removal of deprecated methods

Deprecated setOption and getOption - methods in appender and layouts should be removed.

Ceki

done

JDBCAppender

We currently have two competing JDBCAppenders: one by - Thomas Fenner and the other by Kevin Steppe.

- -

Kevin Steppe stood up and did it.

Kevin Steppe

done

Log4j in applets

In order to minimize network traffic, the size of log4j-core.jar - needs to be reduced to at most 50KB. - -

Log4jME has been released. It's less than 20KB.

Ceki

done

Improved documentation

Log4j documentation needs to be enhanced with configuration - examples and much more hand-holding.

Ceki

ongoing effort

Mapped Diagnostic Contexts

Mapped Diagnostic Contexts are similar to the NDC - except that the MDC is a string to string map instead of - a stack that the user sets when entering a special - context. The PatternLayout has to be - enhanced to support this by extending the %x pattern to - accept an argument. Here is an example: - -

  -    ConversionPattern=3D%d %p %c %x{server} %x{host} - %m%n
  -

- - User code: -

  -    {
  -       MDC.put("server", "totoServer");
  -       MDC.put("host", "someHost");
  -	      
  -       logger.debug("Hello");
  -	      
  -    }
  -

- will print: -

2000-01-24 10:00:00,000 DEBUG totoServer someHost - Hello

- -

To make MDCs truly user friendly - ThreadLocal variables are required. This - will allow the MDC to be inherited by child - threads. ThreadLocal are only supported - under JDK 1.2 and above. In JDK 1.1, the MDC will not - work but won't harm the user application either.

Ceki

done

Enhanced variable substitution support in DOMConfigurator

Ceki

done

FallbackErrorHandler

The FallbackErrorHandler implements the ErrorHandler - interface such that a secondary appender may be - specified. This secondary appender takes over if the primary - appender fails for whatever reason. - -

The DOMConfigurator needs to be extended to support the - FallbackErrorHandler

- -

Ceki

implemented, requires further testing

Ensure backward compatibility of LoggingEvent - objects

To avoid deployment problems we must ensure that - LoggingEvent objects are compatible between 1.2 and 1.1.3. - -

Robert Bushman has proposed a very innovative way for - solving this problem. See - http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01397.html - for further details. -

Ceki

implemented, manually tested, requires automated test cases