Release date: TBA
- + -Apache Log4j 2.0 is not compatible with the previous versions. Please have the following in mind - when upgrading to Log4j 2.0 in your project:
+Apache Log4j2 is not compatible with the previous versions. Please have the following in mind + when upgrading to Log4j2 in your project:
- Log4Jj 2.0 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j + Log4j2 is an upgrade to Log4j that provides significant improvements over its predecessor, Log4j 1.x, and provides many of the improvements available in Logback while fixing some inherent problems in Logback's architecture.
-Some of the features and improvements in Log4j 2.0 are:
+Some of the features and improvements in Log4j2 are:
@@ -46,17 +46,17 @@
- While the Log4j 2.0 API will provide the best performance, support for the SL4J and Commons Logging + While the Log4j2 API will provide the best performance, support for the SL4J and Commons Logging APIs are provided.
- Like Logback, Log4j 2.0 can automatically reload its configuration upon modification. Unlike Logback, + Like Logback, Log4j2 can automatically reload its configuration upon modification. Unlike Logback, it will do so without losing log events while reconfiguration is taking place.
- Like Logback, Log4j 2.0 supports filtering based on context data, markers, regular expressions and
+ Like Logback, Log4j2 supports filtering based on context data, markers, regular expressions and
other components in the Log event and can be specified to apply to all events before being passed
to Loggers or as they pass through appenders. In addition, filters can also be associated with
Loggers. Unlike Logback, a common Filter class can be used in any of these circumstances.
@@ -80,7 +80,7 @@
- Log4j 2.0 requires Java 5 but has will take advantage of enhancements in Java 6 to improve performance.
+ Log4j2 requires Java 5 but has will take advantage of enhancements in Java 6 to improve performance.
Some features may require optional dependencies. These dependencies are
specified in the documentation for those features.
- Log4j 2.0 is now available. The API for Log4j 2.0 is not compatible with Log4j 1.x, however an adapter
+ Log4j2 is now available for testing. The API for Log4j2 is not compatible with Log4j 1.x, however an adapter
is available to allow applications to continue to use the Log4j 1.x API. Adapters are also available for
Commons Logging and SLF4J.
diff --git a/src/site/xdoc/manual/appenders.xml b/src/site/xdoc/manual/appenders.xml
index 7b70d7a437b..fc8e43f0d76 100644
--- a/src/site/xdoc/manual/appenders.xml
+++ b/src/site/xdoc/manual/appenders.xml
@@ -18,7 +18,7 @@
The SocketAppender is an OutputStreamAppender that writes its output to a remote destination
specified by a host and port. The data can be sent over either TCP or UDP and can be sent in any format.
- The default format is to send a Serialized LogEvent. Log4j 2.0 contains a SocketServer which is capable
+ The default format is to send a Serialized LogEvent. Log4j2 contains a SocketServer which is capable
of receiving serialized LogEvents and routing them through the logging system on the server.
Log4j uses the classes shown in the diagram below. Applications using the Log4j 2 API will request a Logger with a specific name from the
+ Applications using the Log4j2 API will request a Logger with a specific name from the
LogManager. The LogManager will locate the appropriate LoggerContext and then obtain the Logger from it.
If the Logger must be created it will be associated with the LoggerConfig that contains either a) the
same name as the Logger, b) the name of a parent package, or c) the root LoggerConfig. LoggerConfig
@@ -45,7 +45,7 @@
developer-chosen criteria.
In Log4j 1.x the Logger Hierarchy was maintained through a relationship between Loggers.
- In Log4j 2 this relationship no longers exists. Instead, the hierarchy is maintained
+ In Log4j2 this relationship no longers exists. Instead, the hierarchy is maintained
in the relationship between LoggerConfig objects.
@@ -183,7 +183,7 @@
LoggerConfigs will be assigned a Log
Level. The set of possible
- levels includes (TRACE, DEBUG, INFO, WARN, ERROR and FATAL). Note that in Log4j 2, the Level is
+ levels includes (TRACE, DEBUG, INFO, WARN, ERROR and FATAL). Note that in Log4j2, the Level is
an Enum and cannot be sub-classed. Users who desire more granularity are encouraged to use
Markers
instead.
@@ -192,7 +192,7 @@
Log4j 1.x
and
Logback
- both have the concept of "Level Inheritance". In Log4j 2, Loggers and LoggerConfigs are two different
+ both have the concept of "Level Inheritance". In Log4j2, Loggers and LoggerConfigs are two different
objects so this concept is implemented differently. Each Logger references the
appropriate LoggerConfig which in turn can reference its parent, thus achieving the same effect.
- Configuration of Log4j 2 can be accomplished in 1 of 4 ways:
+ Configuration of Log4j2 can be accomplished in 1 of 4 ways:
diff --git a/src/site/xdoc/manual/architecture.xml b/src/site/xdoc/manual/architecture.xml
index 028fbb1515a..3a509b9548e 100644
--- a/src/site/xdoc/manual/architecture.xml
+++ b/src/site/xdoc/manual/architecture.xml
@@ -18,7 +18,7 @@
-
+
LoggerContext
This page focuses primarily on configuring Log4j through a configuration file. Information on - programmatically configuring Log4j can be found at Extending Log4j 2. + programmatically configuring Log4j can be found at Extending Log4j2.
- Note that unlike Log4j 1.x, the public Log4j 2 API does not expose methods to add, modify or remove + Note that unlike Log4j 1.x, the public Log4j2 API does not expose methods to add, modify or remove appenders and filters or manipulate the configuration in any way.
@@ -637,7 +637,7 @@- Log4j 2 supports the ability to specify tokens in the configuration as references to properties defined + Log4j2 supports the ability to specify tokens in the configuration as references to properties defined elsewhere. Some of these properties will be resolved when the configuration file is interpreted while others may be passed to components where they will be evaluated at runtime. To accomplish this, Log4j uses variations Apache Commons Lang's @@ -761,13 +761,13 @@ to be able to diagnose problems in the logging configuration or in the configured components. Since logging has not been configured, "normal" logging cannot be used during initialization. In addition, normal logging within appenders could create infinite recursion which Log4j will detect and cause - the recursive events to be ignored. To accomodate this need, the Log4j 2 API includes a + the recursive events to be ignored. To accomodate this need, the Log4j2 API includes a StatusLogger. Components declare an instance of the StatusLogger similar to
- Since StatusLogger implements the Log4j 2 API's Logger interface, all the normal Logger methods may + Since StatusLogger implements the Log4j2 API's Logger interface, all the normal Logger methods may be used.
@@ -884,7 +884,7 @@ log configuration can be used during testing than what is used in production.
- A second approach, which is extensively used by Log4j 2, is to set the log4j.configurationFile property + A second approach, which is extensively used by Log4j2, is to set the log4j.configurationFile property in the method annotated with @BeforeClass in the junit test class. This will allow an arbitrarily named file to be used during the test.
diff --git a/src/site/xdoc/manual/eventlogging.xml b/src/site/xdoc/manual/eventlogging.xml index fb376569c13..cffefd0b915 100644 --- a/src/site/xdoc/manual/eventlogging.xml +++ b/src/site/xdoc/manual/eventlogging.xml @@ -18,12 +18,12 @@
diff --git a/src/site/xdoc/manual/extending.xml b/src/site/xdoc/manual/extending.xml
index 70e0b67c7c6..d9c461d9792 100644
--- a/src/site/xdoc/manual/extending.xml
+++ b/src/site/xdoc/manual/extending.xml
@@ -18,7 +18,7 @@
diff --git a/src/site/xdoc/manual/index.xml b/src/site/xdoc/manual/index.xml
index 22cde4157fb..bb018e0e066 100644
--- a/src/site/xdoc/manual/index.xml
+++ b/src/site/xdoc/manual/index.xml
@@ -23,7 +23,7 @@
Almost every large application includes its own logging or tracing
API. In conformance with this rule, the E.U.
Layouts are used by Appenders to format the LogEvent into a form that meets the needs of whoever will be
consuming the log events. In Log4j 1.x and Logback Layouts were expected to transform an event into a
- String. In Log4j 2.0 Layouts return a byte array. This allows the result of the Layout to be useful in
+ String. In Log4j2 Layouts return a byte array. This allows the result of the Layout to be useful in
many more types of Appenders. However, this means most Layouts need to be configured with a
Charset to
insure the byte array contains correct values.
diff --git a/src/site/xdoc/manual/logsep.xml b/src/site/xdoc/manual/logsep.xml
index cef66525525..090b0f373f5 100644
--- a/src/site/xdoc/manual/logsep.xml
+++ b/src/site/xdoc/manual/logsep.xml
@@ -23,6 +23,6 @@
diff --git a/src/site/xdoc/manual/messages.xml b/src/site/xdoc/manual/messages.xml
index eccc09425b0..885923e42e4 100644
--- a/src/site/xdoc/manual/messages.xml
+++ b/src/site/xdoc/manual/messages.xml
@@ -18,16 +18,16 @@
- Although Log4j 2 provides Logger methods that accept Strings and Objects, all of these are ulitmately
+ Although Log4j2 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
construct Messages of their own and pass them to the Logger. Although it may seem more expensive than
passing the message format and parameters directly to the event, testing has shown that with modern
diff --git a/src/site/xdoc/manual/plugins.xml b/src/site/xdoc/manual/plugins.xml
index 7431edb9ae7..3d575bb2f52 100644
--- a/src/site/xdoc/manual/plugins.xml
+++ b/src/site/xdoc/manual/plugins.xml
@@ -18,7 +18,7 @@
- In Log4j 2 a plugin is declared by adding a Plugin annotation to the class declaration. During
+ In Log4j2 a plugin is declared by adding a Plugin annotation to the class declaration. During
initialization the Configuration will invoke the PluginManager to locate all the Log4j plugins
that are located in the declared packages.
As the configuration is processed the appropriate plugins will be automatically configured and
- initialized. Log4j 2 utilizes a few different types of plugins which are described in the follownig
+ initialized. Log4j2 utilizes a few different types of plugins which are described in the follownig
sections.
Log4j introduced the concept of the Mapped Diagnostic Context or MDC. It has been documented and
@@ -36,10 +36,10 @@
SLF4J/Logback followed with its own implementation of the MDC, which is documented very well at
Mapped Diagnostic Context.
Log4j 2 continues with the idea of the MDC and the NDC but merges them into a single Thread Context.
+ Log4j2 continues with the idea of the MDC and the NDC but merges them into a single Thread Context.
The Thread Context Map is the equivalent of the MDC and the Thread Context Stack is the equivalent of the
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.
+ frequently referred to as the MDC and NDC in Log4j2 since they are already well known by those acronyms.
Most real-world systems have to deal with multiple clients simultaneously. In a typical multithreaded
diff --git a/src/site/xdoc/performance.xml b/src/site/xdoc/performance.xml
index a845b013a8f..9f37ab0bc0d 100644
--- a/src/site/xdoc/performance.xml
+++ b/src/site/xdoc/performance.xml
@@ -41,7 +41,7 @@
- The best approach to avoid the cost of parameter construction is to use Log4J 2.0's formatting
+ The best approach to avoid the cost of parameter construction is to use Log4j2's formatting
capabilities. For example, instead of the above write:
This is the cost of formatting the log output and sending it to its target destination. Here again,
a serious effort was made to make layouts (formatters) perform as quickly as possible. The same
- is true for appenders. One of the fundamental tenants of Log4j 2.0 is to use immutable objects whenever
+ is true for appenders. One of the fundamental tenants of Log4j2 is to use immutable objects whenever
possible and to lock at the lowest granularity possible. However, the cost of actually formatting and
delivering log events will never be insignificant. For example, the results of writing to a simple log
file using the same format using Log4j, Logback and Log4j 2 are:
-
Introduction
Fish Tagging
Log4j: 4
Logback: 5
- Log4j 2.0: 3
+ Log4j2: 3
The numbers above will vary slightly from run to run so the only conclusion that should be
drawn is that all 3 frameworks perform similarly on this task.
@@ -63,7 +63,7 @@
Log4j: 188
Logback: 183
- Log4j 2.0: 188
+ Log4j2: 188
Again, no conclusion should be drawn regarding relative differences between the frameworks on
@@ -71,7 +71,7 @@
the level.
logger.debug("Entry number: {} is {}", i, entry[i]);
@@ -80,7 +80,7 @@
Log4j: Not supported
Logback: 9
- Log4j 2.0: 4
+ Log4j2: 4
These results show that the difference in performance between the call to isDebugEnabled and
logger.debug is barely discernable.
@@ -122,14 +122,14 @@
Log4j: 4220
Logback: 9671
- Log4j 2.0: 4615
+ Log4j2: 4615