Return-Path:
- The Log4Jj 2.0 API provides the interface that applications should code to and provides the - adapter components required for implementers to create a logging implementation. Although Log4j 2 - is broken up between an API and an implementation, the primary purpose of doing so was not to - allow multiple implementations, although that is certainly possible, but to clearly define - what classes and methods are safe to use in "normal" application code. -
-- No introduction would be complete without the customary Hello, World example. Here is ours. First, - a Logger with the name "HelloWorld" is obtained from the LogManager. Next, the logger is used to - write the "Hello, World!" message, however the message will be written only if the Logger is - configured to allow informational messages. -
-Sample class that uses EventLogger.
+The EventLogger class uses a Logger named "EventLogger". EventLogger uses a logging level + of OFF as the default to indicate that it cannot be filtered. These events can be + formatted for printing using the + StructuredDataLayout. +
+- The Log4Jj 2.0 API provides the interface that applications should code to and provides the - adapter components required for implementers to create a logging implementation. Although Log4j 2 - is broken up between an API and an implementation, the primary purpose of doing so was not to - allow multiple implementations, although that is certainly possible, but to clearly define - what classes and methods are safe to use in "normal" application code. -
-- No introduction would be complete without the customary Hello, World example. Here is ours. First, - a Logger with the name "HelloWorld" is obtained from the LogManager. Next, the logger is used to - write the "Hello, World!" message, however the message will be written only if the Logger is - configured to allow informational messages. + The Logger class provides logging methods that are quite useful for following the + execution path of applications. These methods generate logging events that can be filtered + separately from other debug logging. Liberal use of these methods is encouraged as the output has + been found to +
- The output from the call to logger.info() will vary significantly depending on the configuration - used. See the Configuration section for more details. + The two most used methods are the entry() and exit() methods. entry() should be placed at the + beginning of methods, except perhaps ofr simple getters and setters. entry() can be called + passing from 0 to 4 parameters. Typically these will be parameters passed to the method. + The entry() method logs with a level of TRACE and uses a Marker with a name of "ENTER" which + is also a "FLOW" Marker.
-- Frequently the purpose of logging is to provide information about what is happening in the system, - which requires including information about the objects being manipulated. In Log4j 1.x this could - be accomplished by doing: + The exit() method should be placed before any return statement or as the last statement of + methods without a return. exit() can be called with or without a parameter. Typically, methods + that return void will use exit() while methods that return an Object will use exit(Object obj). + The entry() method logs with a level of TRACE and uses a Marker with a name of "EXIT" which is + also a "FLOW" Marker.
-- Doing this repeatedly has the effect of making the code feel like it is more about logging than the - actual task at hand. In addition, it results in the logging level being checked twice; once on the - call to isDebugEnabled and once on the debug method. A better alternative would be: + The throwing() method can be used by an application when it is throwing an exception that is + unlikely to be handled, such as a RuntimeExcpetion. This will insure that proper diagnostics + are available if needed. The logging event generated will have a level of ERROR and will have + an associated Marker with a name of "THROWING" which is also an "EXCEPTION" Marker.
-- With the code above the logging level will only be checked once and the String construction will - only occur when debug logging is enabled. + The catching() method can be used by an application when it catches an Exception that it is not + going to rethrow, either explicitely or attached to another Exception. The logging event generated + will have a level of ERROR and will have an associated Marker with a name of "CATCHING" which is + also an "EXCEPTION" Marker.
-+ The following example shows a simple application using these methods in a fairly typcial manner. The + throwing() is not present since no Exceptions are explicitely thrown and not handled. +
++ This test application uses the preceding service to generate logging events. +
++ The configuration below will cause all output to be routed to target/test.log. The pattern for + the FileAppender includes the class name, line number and method name. Including these + in the pattern are critical for the log to be of value. +
++ Here is the output that results from the Java classes and configuration above. +
++ Simply changing the root logger level to DEBUG in the example above will reduce the output + considerably. +
+- The Log4Jj 2.0 API provides the interface that applications should code to and provides the - adapter components required for implementers to create a logging implementation. Although Log4j 2 - is broken up between an API and an implementation, the primary purpose of doing so was not to - allow multiple implementations, although that is certainly possible, but to clearly define - what classes and methods are safe to use in "normal" application code. -
-- No introduction would be complete without the customary Hello, World example. Here is ours. First, - a Logger with the name "HelloWorld" is obtained from the LogManager. Next, the logger is used to - write the "Hello, World!" message, however the message will be written only if the Logger is - configured to allow informational messages. -
-- The output from the call to logger.info() will vary significantly depending on the configuration - used. See the Configuration section for more details. -
-- Frequently the purpose of logging is to provide information about what is happening in the system, - which requires including information about the objects being manipulated. In Log4j 1.x this could - be accomplished by doing: -
-- Doing this repeatedly has the effect of making the code feel like it is more about logging than the - actual task at hand. In addition, it results in the logging level being checked twice; once on the - call to isDebugEnabled and once on the debug method. A better alternative would be: + In the example above it is now possible to add MarkerFilters to only allow SQL update operations + to be logged, all SQL updates to be logged or to log everything in MyApp.
-- With the code above the logging level will only be checked once and the String construction will - only occur when debug logging is enabled. + Some important rules about Markers must be considered when using them. +
Although Log4j 2 provides Logger methods that accept Strings and Objects, all of these are ulitmately captured in Message objects that are then associated with the log event. Applications are free to @@ -66,10 +66,110 @@ are encountered. With Messages the Layout has the option of delegating the formatting to the Message or performing its formatting based on the type of Message encountered.
++ Borrowing from the earlier example illustrating Markers to identify SQL statements being logged, Messages + can also be leveraged. First, the Message is defined. +
++ Next we can use the message in our application. +
++ Notice that in contrast to the prior version of this example, the logger.debug in doUpdate no longer + needs to be wrapped in an isDebugEnabled call as creation of the SQLMessage is on the same order of + magnitude of performing that check. Furthermore, all the formatting of the SQL columns is now hidden + in the SQLMessage instead of having to take place in the business logic. Finally, if desired, Filters + and/or Layouts can be written to take special action when an SQLMessage is encountered. +
-A FormattedMessage will have setFormat and getFormat methods. The setFormat method may be called by a Layout to provide advice on how the Message should be formatted. If the Message doesn't recognize the @@ -77,9 +177,8 @@ StructuredDataMessage which accepts a format String of "XML" which will cause it to format the event data as XML instead of the RFC 5424 format.
-LocalizedMessage is provided primarily to provide compatibility with Log4j 1.x. Generally, @@ -91,60 +190,52 @@ LocalizedMessage will attempt to locate a bundle with the name of the Logger used to log the event. The parameters to the Message will be incorporated into the Message whereever the "{}" placeholders occur.
-LoggerNameAwareMessage is an interface with a setLoggerName method. This method will be called during event construction so that the Message has the name of the Logger used to log the event when the message is being formatted.
-A MapMessage contains a Map of String keys and values. MapMessage implements FormattedMessage and accepts a format specifier of "XML", in which case the Map will be formatted as XML. Otherwise, the Map will be formatted as "key1=value1 key2=value2...".
-Formats an Object by calling its toString method.
-ParameterizedMessage handles messages that contain "{}" in the format to represent replaceable tokens and the replacement parameters.
-SimpleMessage contains a String that requires no formatting.
-StructuredDataMessage allows applications to add items to a Map as well as set the id to allow a message to be formatted as a Structured Data element in accordance with RFC 5424.
-A ThreadDumpMessage, if logged, will generate stack traces for all threads. If running on Java 6+ the stack traces will include any locks that are held.
-A TimestampMessage will provide a getTimestamp method that is called during event construction. The timestamp in the Message will be used in lieu of the current timestamp. Modified: logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/src/site/xdoc/manual/thread-context.xml URL: http://svn.apache.org/viewvc/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/src/site/xdoc/manual/thread-context.xml?rev=1240834&r1=1240833&r2=1240834&view=diff ============================================================================== --- logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/src/site/xdoc/manual/thread-context.xml (original) +++ logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/src/site/xdoc/manual/thread-context.xml Sun Feb 5 21:50:04 2012 @@ -23,8 +23,9 @@
-Log4j introduced the concept of the Mapped Diagnostic Context or MDC. It has been documented and discussed in numerous places including Log4j MDC: What and Why and @@ -40,8 +41,7 @@ NDC. Although these are frequently used for purposes other than diagnosing problems, they are still frequently referred to as the MDC and NDC in Log4j 2 since they are already well known by those acronyms.
-Most real-world systems have to deal with multiple clients simultaneously. In a typical multithreaded implementation of such asystem, different threads will handle different clients. Logging is especially well suited to trace and debug complex distributed applications. A common approach to @@ -109,8 +109,7 @@ ThreadContext class are static.
-The PatternLayout provides mechanisms to print the contents of the ThreadContext Map and Stack. Using %X by itself will cause the full contents of the Map to be included while %X{key} will cause the value