Log4j настройка файлов логов

Log4j настройка файлов логов


Inserting log requests into the application code requires a fair amount of planning and effort. Observation shows that approximately 4 percent of code is dedicated to logging. Consequently, even moderately sized applications will have thousands of logging statements embedded within their code. Given their number, it becomes imperative to manage these log statements without the need to modify them manually.

Configuration of Log4j 2 can be accomplished in 1 of 4 ways:

  1. Through a configuration file written in XML, JSON, YAML, or properties format.
  2. Programmatically, by creating a ConfigurationFactory and Configuration implementation.
  3. Programmatically, by calling the APIs exposed in the Configuration interface to add components to the default configuration.
  4. Programmatically, by calling methods on the internal Logger class.

This page focuses primarily on configuring Log4j through a configuration file. Information on programmatically configuring Log4j can be found at Extending Log4j 2 and Programmatic Log4j Configuration.

Note that unlike Log4j 1.x, the public Log4j 2 API does not expose methods to add, modify or remove appenders and filters or manipulate the configuration in any way.

Automatic Configuration

Log4j has the ability to automatically configure itself during initialization. When Log4j starts it will locate all the ConfigurationFactory plugins and arrange them in weighted order from highest to lowest. As delivered, Log4j contains four ConfigurationFactory implementations: one for JSON, one for YAML, one for properties, and one for XML.

  1. Log4j will inspect the «log4j.configurationFile» system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension. Note that this is not restricted to a location on the local file system and may contain a URL.
  2. If no system property is set the properties ConfigurationFactory will look for log4j2-test.properties in the classpath.
  3. If no such file is found the YAML ConfigurationFactory will look for log4j2-test.yaml or log4j2-test.yml in the classpath.
  4. If no such file is found the JSON ConfigurationFactory will look for log4j2-test.json or log4j2-test.jsn in the classpath.
  5. If no such file is found the XML ConfigurationFactory will look for log4j2-test.xml in the classpath.
  6. If a test file cannot be located the properties ConfigurationFactory will look for log4j2.properties on the classpath.
  7. If a properties file cannot be located the YAML ConfigurationFactory will look for log4j2.yaml or log4j2.yml on the classpath.
  8. If a YAML file cannot be located the JSON ConfigurationFactory will look for log4j2.json or log4j2.jsn on the classpath.
  9. If a JSON file cannot be located the XML ConfigurationFactory will try to locate log4j2.xml on the classpath.
  10. If no configuration file could be located the DefaultConfiguration will be used. This will cause logging output to go to the console.

An example application named MyApp that uses log4j can be used to illustrate how this is done.

MyApp begins by importing log4j related classes. It then defines a static logger variable with the name MyApp which happens to be the fully qualified name of the class.

MyApp uses the Bar class defined in the packagecom.foo.

Log4j will provide a default configuration if it cannot locate a configuration file. The default configuration, provided in the DefaultConfiguration class, will set up:

  • A ConsoleAppender attached to the root logger.
  • A PatternLayout set to the pattern «%d [%t] %-5level %logger <36>— %msg%n» attached to the ConsoleAppender

Note that by default Log4j assigns the root logger to Level.ERROR.

The output of MyApp would be similar to:

As was described previously, Log4j will first attempt to configure itself from configuration files. A configuration equivalent to the default would look like:

Once the file above is placed into the classpath as log4j2.xml you will get results identical to those listed above. Changing the root level to trace will result in results similar to:

Note that status logging is disabled when the default configuration is used.


Perhaps it is desired to eliminate all the TRACE output from everything except com.foo.Bar. Simply changing the log level would not accomplish the task. Instead, the solution is to add a new logger definition to the configuration:

With this configuration all log events from com.foo.Bar will be recorded while only error events will be recorded from all other components.

In the previous example all the events from com.foo.Bar were still written to the Console. This is because the logger for com.foo.Bar did not have any appenders configured while its parent did. In fact, the following configuration

would result in

Notice that the trace messages from com.foo.Bar appear twice. This is because the appender associated with logger com.foo.Bar is first used, which writes the first instance to the Console. Next, the parent of com.foo.Bar, which in this case is the root logger, is referenced. The event is then passed to its appender, which is also writes to the Console, resulting in the second instance. This is known as additivity. While additivity can be quite a convenient feature (as in the first previous example where no appender reference needed to be configured), in many cases this behavior is considered undesirable and so it is possible to disable it by setting the additivity attribute on the logger to false:

Once an event reaches a logger with its additivity set to false the event will not be passed to any of its parent loggers, regardless of their additivity setting.

Automatic Reconfiguration

When configured from a File, Log4j has the ability to automatically detect changes to the configuration file and reconfigure itself. If the monitorInterval attribute is specified on the configuration element and is set to a non-zero value then the file will be checked the next time a log event is evaluated and/or logged and the monitorInterval has elapsed since the last check. The example below shows how to configure the attribute so that the configuration file will be checked for changes only after at least 30 seconds have elapsed. The minimum interval is 5 seconds.

Chainsaw can automatically process your log files (Advertising appender configurations)

Log4j provides the ability to ‘advertise’ appender configuration details for all file-based appenders as well as socket-based appenders. For example, for file-based appenders, the file location and the pattern layout in the file are included in the advertisement. Chainsaw and other external systems can discover these advertisements and use that information to intelligently process the log file.

The mechanism by which an advertisement is exposed, as well as the advertisement format, is specific to each Advertiser implementation. An external system which would like to work with a specific Advertiser implementation must understand how to locate the advertised configuration as well as the format of the advertisement. For example, a ‘database’ Advertiser may store configuration details in a database table. An external system can read that database table in order to discover the file location and the file format.

Log4j provides one Advertiser implementation, a ‘multicastdns’ Advertiser, which advertises appender configuration details via IP multicast using the http://jmdns.sourceforge.net library.

Chainsaw automatically discovers log4j’s multicastdns-generated advertisements and displays those discovered advertisements in Chainsaw’s Zeroconf tab (if the jmdns library is in Chainsaw’s classpath). To begin parsing and tailing a log file provided in an advertisement, just double-click the advertised entry in Chainsaw’s Zeroconf tab. Currently, Chainsaw only supports FileAppender advertisements.

To advertise an appender configuration:

  • Add the JmDns library from http://jmdns.sourceforge.net to the application classpath
  • Set the ‘advertiser’ attribute of the configuration element to ‘multicastdns’
  • Set the ‘advertise’ attribute on the appender element to ‘true’
  • If advertising a FileAppender-based configuration, set the ‘advertiseURI’ attribute on the appender element to an appropriate URI

FileAppender-based configurations require an additional ‘advertiseURI’ attribute to be specified on the appender. The ‘advertiseURI’ attribute provides Chainsaw with information on how the file can be accessed. For example, the file may be remotely accessible to Chainsaw via ssh/sftp by specifying a Commons VFS (http://commons.apache.org/proper/commons-vfs/) sftp:// URI, an http:// URI may be used if the file is accessible through a web server, or a file:// URI can be specified if accessing the file from a locally-running instance of Chainsaw.

Here is an example advertisement-enabled appender configuration which can be used by a locally-running Chainsaw to automatically tail the log file (notice the file:// advertiseURI):

Please note, you must add the JmDns library from http://jmdns.sourceforge.net to your application classpath in order to advertise with the ‘multicastdns’ advertiser.

Configuration Syntax

As of version 2.9, for security reasons, Log4j does not process DTD in XML files. If you want to split the configuration in multiple files, use XInclude or Composite Configuration.

As the previous examples have shown as well as those to follow, Log4j allows you to easily redefine logging behavior without needing to modify your application. It is possible to disable logging for certain parts of the application, log only when specific criteria are met such as the action being performed for a specific user, route output to Flume or a log reporting system, etc. Being able to do this requires understanding the syntax of the configuration files.

The configuration element in the XML file accepts several attributes:

The level of internal Log4j events that should be logged to the console. Valid values for this attribute are «trace», «debug», «info», «warn», «error» and «fatal». Log4j will log details about initialization, rollover and other internal actions to the status logger. Setting status=»trace» is one of the first tools available to you if you need to troubleshoot log4j.

(Alternatively, setting system property log4j2.debug will also print internal Log4j2 logging to the console, including internal logging that took place before the configuration file was found.)

Attribute Name Description
advertiser (Optional) The Advertiser plugin name which will be used to advertise individual FileAppender or SocketAppender configurations. The only Advertiser plugin provided is ‘multicastdns».
dest Either «err» for stderr, «out» for stdout, a file path, or a URL.
monitorInterval The minimum amount of time, in seconds, that must elapse before the file configuration is checked for changes.
name The name of the configuration.
packages A comma separated list of package names to search for plugins. Plugins are only loaded once per classloader so changing this value may not have any effect upon reconfiguration.
schema Identifies the location for the classloader to located the XML Schema to use to validate the configuration. Only valid when strict is set to true. If not set no schema validation will take place.
shutdownHook Specifies whether or not Log4j should automatically shutdown when the JVM shuts down. The shutdown hook is enabled by default but may be disabled by setting this attribute to «disable»
shutdownTimeout Specifies how many milliseconds appenders and background tasks will get to shutdown when the JVM shuts down. Default is zero which mean that each appender uses its default timeout, and don’t wait for background tasks. Not all appenders will honor this, it is a hint and not an absolute guarantee that the shutdown procedure will not take longer. Setting this too low increase the risk of losing outstanding log events not yet written to the final destination. See LoggerContext.stop(long, java.util.concurrent.TimeUnit). (Not used if shutdownHook is set to «disable».)
strict Enables the use of the strict XML format. Not supported in JSON configurations.
verbose Enables diagnostic information while loading plugins.

Configuration with XML

Log4j can be configured using two XML flavors; concise and strict. The concise format makes configuration very easy as the element names match the components they represent however it cannot be validated with an XML schema. For example, the ConsoleAppender is configured by declaring an XML element named Console under its parent appenders element. However, element and attribute names are are not case sensitive. In addition, attributes can either be specified as an XML attribute or as an XML element that has no attributes and has a text value. So

The file below represents the structure of an XML configuration, but note that the elements in italics below represent the concise element names that would appear in their place.

See the many examples on this page for sample appender, filter and logger declarations.

Strict XML

In addition to the concise XML format above, Log4j allows configurations to be specified in a more «normal» XML manner that can be validated using an XML Schema. This is accomplished by replacing the friendly element names above with their object type as shown below. For example, instead of the ConsoleAppender being configuerd using an element named Console it is instead configured as an appender element with a type attribute containing «Console».

Below is a sample configuration using the strict format.

Configuration with JSON

In addition to XML, Log4j can be configured using JSON. The JSON format is very similar to the concise XML format. Each key represents the name of a plugin and the key/value pairs associated with it are its attributes. Where a key contains more than a simple value it itself will be a subordinate plugin. In the example below, ThresholdFilter, Console, and PatternLayout are all plugins while the Console plugin will be assigned a value of STDOUT for its name attribute and the ThresholdFilter will be assigned a level of debug.

Note that in the RoutingAppender the Route element has been declared as an array. This is valid because each array element will be a Route component. This won’t work for elements such as appenders and filters, where each element has a different name in the concise format. Appenders and filters can be defined as array elements if each appender or filter declares an attribute named «type» that contains the type of the appender. The following example illustrates this as well as how to declare multiple loggers as an array.

Additional runtime dependencies are required for using JSON configuration files.

Configuration with YAML

Log4j also supports using YAML for configuration files. The structure follows the same pattern as both the XML and YAML configuration formats. For example:

Additional runtime dependencies are required for using YAML configuration files.

Configuration with Properties

As of version 2.4, Log4j now supports configuration via properties files. Note that the property syntax is NOT the same as the syntax used in Log4j 1. Like the XML and JSON configurations, properties configurations define the configuration in terms of plugins and attributes to the plugins.

Prior to version 2.6, the properties configuration requires that you list the identifiers of the appenders, filters and loggers, in a comma separated list in properties with those names. Each of those components will then be expected to be defined in sets of properties that begin with component. .. The identifier does not have to match the name of the component being defined but must uniquely identify all the attributes and subcomponents that are part of the component. If the list of identifiers is not present the identifer must not contain a ‘.’. Each individual component MUST have a «type» attribute specified that identifies the component’s Plugin type.

As of version 2.6, this list of identifiers is no longer required as names are inferred upon first usage, however if you wish to use more complex identifies you must still use the list. If the list is present it will be used.

Unlike the base components, when creating subcomponents you cannot specify an element containing a list of identifiers. Instead, you must define the wrapper element with its type as is shown in the policies definition in the rolling file appender below. You then define each of the subcomponents below that wrapper element, as the TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy are defined below.

Properties configuration files support the advertiser, monitorInterval, name, packages, shutdownHook, shutdownTimeout, status, verbose, and dest attrbutes. See Configuration Syntax for the definitions of these attributes.

Configuring Loggers

An understanding of how loggers work in Log4j is critical before trying to configure them. Please reference the Log4j architecture if more information is required. Trying to configure Log4j without understanding those concepts will lead to frustration.

A LoggerConfig is configured using the logger element. The logger element must have a name attribute specified, will usually have a level attribute specified and may also have an additivity attribute specified. The level may be configured with one of TRACE, DEBUG, INFO, WARN, ERROR, ALL or OFF. If no level is specified it will default to ERROR. The additivity attribute may be assigned a value of true or false. If the attribute is omitted the default value of true will be used.

Capturing location information (the class name, file name, method name, and line number of the caller) can be slow. Log4j tries to optimize this by reducing the size of the stack that must be traversed to find the caller of the logging method. It does this by determining if any component that might be accessed requires location information. This can cause performance issues if a logger is configured at a level like trace or debug with the expectation that most logs will be filtered on an Appender reference or Appender as Log4j will calculate the location information even though the log event is going to be discarded. To disable this behavior the includeLocation attribute can be set to false on the LoggerConfig. This will cause Log4j to defer calculating the location information until absolutely necessary.

A LoggerConfig (including the root LoggerConfig) can be configured with properties that will be added to the properties copied from the ThreadContextMap. These properties can be referenced from Appenders, Filters, Layouts, etc just as if they were part of the ThreadContext Map. The properties can contain variables that will be resolved either when the configuration is parsed or dynamically when each event is logged. See Property Substitution for more information on using variables.

The LoggerConfig may also be configured with one or more AppenderRef elements. Each appender referenced will become associated with the specified LoggerConfig. If multiple appenders are configured on the LoggerConfig each of them be called when processing logging events.

Every configuration must have a root logger. If one is not configured the default root LoggerConfig, which has a level of ERROR and has a Console appender attached, will be used. The main differences between the root logger and other loggers are

  1. The root logger does not have a name attribute.
  2. The root logger does not support the additivity attribute since it has no parent.

Configuring Appenders

An appender is configured either using the specific appender plugin’s name or with an appender element and the type attribute containing the appender plugin’s name. In addition each appender must have a name attribute specified with a value that is unique within the set of appenders. The name will be used by loggers to reference the appender as described in the previous section.

Most appenders also support a layout to be configured (which again may be specified either using the specific Layout plugin’s name as the element or with «layout» as the element name along with a type attribute that contains the layout plugin’s name. The various appenders will contain other attributes or elements that are required for them to function properly.

Configuring Filters

Log4j allows a filter to be specified in any of 4 places:

  1. At the same level as the appenders, loggers and properties elements. These filters can accept or reject events before they have been passed to a LoggerConfig.
  2. In a logger element. These filters can accept or reject events for specific loggers.
  3. In an appender element. These filters can prevent or cause events to be processed by the appender.
  4. In an appender reference element. These filters are used to determine if a Logger should route the event to an appender.

Although only a single filter element can be configured, that element may be the filters element which represents the CompositeFilter. The filters element allows any number of filter elements to be configured within it. The following example shows how multiple filters can be configured on the ConsoleAppender.

Property Substitution

Log4j 2 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 of Apache Commons Lang’s StrSubstitutor and StrLookup classes. In a manner similar to Ant or Maven, this allows variables declared as $ to be resolved using properties declared in the configuration itself. For example, the following example shows the filename for the rolling file appender being declared as a property.

While this is useful, there are many more places properties can originate from. To accommodate this, Log4j also supports the syntax $ where the prefix identifies tells Log4j that variable name should be evaluated in a specific context. See the Lookups manual page for more details. The contexts that are built in to Log4j are:

Prefix Context
base64 Base64 encoded data. The format is $. For example: $ yields Hello World!.
bundle Resource bundle. The format is $. The bundle name follows package naming conventions, for example: $.
ctx Thread Context Map (MDC)
date Inserts the current date and/or time using the specified format
env System environment variables. The formats are $ and $.
jndi A value set in the default JNDI Context.
jvmrunargs A JVM input argument accessed through JMX, but not a main argument; see RuntimeMXBean.getInputArguments(). Not available on Android.
log4j Log4j configuration properties. The expressions $ and $ respectively provide the absolute path to the log4j configuration file and its parent folder.
main A value set with MapLookup.setMainArguments(String[])
map A value from a MapMessage
sd A value from a StructuredDataMessage. The key «id» will return the name of the StructuredDataId without the enterprise number. The key «type» will return the message type. Other keys will retrieve individual elements from the Map.
sys System properties. The formats are $ and $.

Default Properites

A default property map can be declared in the configuration file by placing a Properties element directly after the Configuration element and before any Loggers, Filters, Appenders, etc. are declared. If the value cannot be located in the specified lookup the value in the default property map will be used. The default map is pre-populated with a value for «hostName» that is the current system’s host name or IP address and the «contextName» with is the value of the current logging context. See many places a Properties element is used in this section for examples.

Default properties may also be specified in the Lookup by using the syntax $. In some cases the key might contain a leading ‘-‘. When this is the case an escape character must be included, such as $. This would use the MainMapLookup for a key named —file. If the key is not found then app.properties would be used as the default value.

Lookup Variables with Multiple Leading ‘$’ Characters

An interesting feature of StrLookup processing is that when a variable reference is declared with multiple leading ‘$’ characters each time the variable is resolved the leading ‘$’ is simply removed. In the previous example the «Routes» element is capable of resolving the variable at runtime. To allow this the prefix value is specified as a variable with two leading ‘$’ characters. When the configuration file is first processed the first ‘$’ character is simply removed. Thus, when the Routes element is evaluated at runtime it is the variable declaration «$» which causes the event to be inspected for a StructuredDataMessage and if one is present the value of its type attribute to be used as the routing key. Not all elements support resolving variables at runtime. Components that do will specifically call that out in their documentation.

If no value is found for the key in the Lookup associated with the prefix then the value associated with the key in the properties declaration in the configuration file will be used. If no value is found the variable declaration will be returned as the value. Default values may be declared in the configuration by doing:

As a footnote, it is worth pointing out that the variables in the RollingFile appender declaration will also not be evaluated when the configuration is processed. This is simply because the resolution of the whole RollingFile element is deferred until a match occurs. See RoutingAppender for more information.


Log4j provides support for JSR 223 scripting languages to be used in some of its components. Any language that provides support for the JSR 223 scripting engine may be used. A list of the languages and bindings for them can be found at the Scripting Engine web site. However, some of the languages listed there, such as JavaScript, Groovy and Beanshell, directly support the JSR 223 scripting framework and only require that the jars for that language be installed.

The components that support using scripts do so by allowing a

If the status attribute on the Configuration element is set to DEBUG the list of script engines currently installed and their attributes will be listed. Although some engines may say they are not thread safe, Log4j takes steps to insure that the scripts will run in a thread-safe manner if the engine advertises that it is not thread safe.

When the scripts are executed they will be provided with a set of variables that should allow them to accomplish whatever task they are expected to perform. See the documentation for the individual components for the list of variables that are available to the script.

The components that support scripting expect a return value to be passed back to the calling Java code. This is not a problem for several of the scripting languages, but Javascript does not allow a return statement unless it is within a function. However, Javascript will return the value of the last statement executed in the script. As a consequence, code such as that shown below will result in the desired behavior.

A special note on Beanshell

JSR 223 scripting engines are supposed to identify that they support the Compilable interface if they support compiling their scripts. Beanshell does this. However, whenever the compile method is called it throws an Error (not an Exception). Log4j catches this but will log the warning shown below for each Beanshell script when it tries to compile them. All Beanshell scripts will then be interpreted on each execution.


XML configuration files can include other files with XInclude. Here is an example log4j2.xml file that includes two other files:

Composite Configuration

Log4j allows multiple configuration files to be used by specifying them as a list of comma separated file paths on log4j.configurationFile or, when using urls, by adding secondary configuration locations as query parameters named «override». The merge logic can be controlled by specifying a class that implements the MergeStrategy interface on the log4j.mergeStrategy property. The default merge strategy will merge the files using the following rules:

  1. The global configuration attributes are aggregated with those in later configurations replacing those in previous configurations, with the exception that the highest status level and the lowest monitorInterval greater than 0 will be used.
  2. Properties from all configurations are aggregated. Duplicate properties replace those in previous configurations.
  3. Filters are aggregated under a CompositeFilter if more than one Filter is defined. Since Filters are not named duplicates may be present.
  4. Scripts and ScriptFile references are aggregated. Duplicate definiations replace those in previous configurations.
  5. Appenders are aggregated. Appenders with the same name are replaced by those in later configurations, including all of the Appender’s subcomponents.
  6. Loggers are all aggregated. Logger attributes are individually merged with duplicates being replaced by those in later configurations. Appender references on a Logger are aggregated with duplicates being replaced by those in later configurations. Filters on a Logger are aggregated under a CompositeFilter if more than one Filter is defined. Since Filters are not named duplicates may be present. Filters under Appender references included or discarded depending on whether their parent Appender reference is kept or discarded.

Status Messages

Troubleshooting tip for the impatient:

From log4j-2.9 onward, log4j2 will print all internal logging to the console if system property log4j2.debug is defined (with any or no value).

Prior to log4j-2.9, there are two places where internal logging can be controlled:

  • Before a configuration is found, status logger level can be controlled with system property org.apache.logging.log4j.simplelog.StatusLogger.level.
  • After a configuration is found, status logger level can be controlled in the configuration file with the «status» attribute, for example: .

Just as it is desirable to be able to diagnose problems in applications, it is frequently necessary 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 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 be used.

When configuring Log4j it is sometimes necessary to view the generated status events. This can be accomplished by adding the status attribute to the configuration element or a default value can be provided by setting the «Log4jDefaultStatusLevel» system property. Valid values of the status attribute are «trace», «debug», «info», «warn», «error» and «fatal». The following configuration has the status attribute set to debug.

During startup this configuration produces:

If the status attribute is set to error than only error messages will be written to the console. This makes troubleshooting configuration errors possible. As an example, if the configuration above is changed to have the status set to error and the logger declaration is:

the following error message will be produced.

Applications may wish to direct the status output to some other destination. This can be accomplished by setting the dest attribute to either «err» to send the output to stderr or to a file location or URL. This can also be done by insuring the configured status is set to OFF and then configuring the application programmatically such as:

Testing in Maven

Maven can run unit and functional tests during the build cycle. By default, any files placed in src/test/resources are automatically copied to target/test-classes and are included in the classpath during execution of any tests. As such, placing a log4j2-test.xml into this directory will cause it to be used instead of a log4j2.xml or log4j2.json that might be present. Thus a different 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 in the method annotated with @BeforeClass in the junit test class. This will allow an arbitrarily named file to be used during the test.

A third approach, also used extensively by Log4j 2, is to use the LoggerContextRule JUnit test rule which provides additional convenience methods for testing. This requires adding the log4j-core test-jar dependency to your test scope dependencies. For example:

System Properties

The Log4j documentation references a number of System Properties that can be used to control various aspects of Log4j 2 behavior. The table below lists these properties along with their default value and a description of what they control. Any spaces present in the property name are for visual flow and should be removed.

Note that beginning in Log4j 2.10, all system property names have been normalized to follow a consistent naming scheme. While the old property names are still supported for backwards compatibility, it is recommended to update configurations to use the new style. This system is extensible and is enabled through the PropertySource interface. Additional property source classes can be added through the standard ServiceLoader mechanism in Java SE.

Properties can be overridden by sources with a lower number priority (e.g. -100 comes before 100). The following sources are all available by default:

PropertySource priorities and descriptions

Source Priority Description
Environment Variables -100 Environment variables are all prefixed with LOG4J_, are in all caps, and words are all separated by underscores. Only this naming scheme is support for environment variables as there were no old naming schemes to maintain compatibility with.
log4j2.component.properties file Including this file on the classpath can be used as an alternative to providing properties as system properties. This has priority over system properties, but they can be overridden by environment variables as described above.
System Properties 100 All properties can be set using normal system property patterns. These have the lowest priority and can be overridden by included properties files or environment variables.

The following is a list of available global configuration properties. Note that these can only be set once per JVM process unlike configuration settings available in configuration files. The Property Name column contains the name used in properties files and system properties; Environemt Variable for the equivalent environment variable; and Legacy Property Name for the pre-2.10 name.

Log4j 2 global configuration properties

The StatusLogger logs events that occur in the logging system to the console. During configuration, AbstractConfiguration registers a StatusConsoleListener with the StatusLogger that may redirect status log events from the default console output to a file. The listener also supports fine-grained filtering. This system property specifies the default status log level for the listener to use if the configuration does not specify a status level.

Note: this property is used by the log4j-core implementation only after a configuration file has been found.

The initial «listenersLevel» of the StatusLogger. If StatusLogger listeners are added, the «listenerLevel» is changed to that of the most verbose listener. If any listeners are registered, the listenerLevel is used to quickly determine if an interested listener exists.

By default, StatusLogger listeners are added when a configuration is found and by the JMX StatusLoggerAdmin MBean. For example, if a configuration contains , a listener with statusLevel TRACE is registered and the StatusLogger listenerLevel is set to TRACE, resulting in verbose status messages displayed on the console.

If no listeners are registered, the listenersLevel is not used, and the StatusLogger output level is determined by StatusLogger.getLogger().getLevel() (see property org.apache.logging.log4j.simplelog .StatusLogger.level).

Used by Async Loggers and the AsyncAppender to maintain application throughput even when the underlying appender cannot keep up with the logging rate and the queue is filling up.

If no value is specified (the default) events are never discarded. If the queue is full, the logger call blocks until the event can be added to the queue.

Specify Discard to drop events whose level is equal or less than the threshold level (INFO by default) when the queue is full.


Property Name
(Legacy Property Name)
Environment Variable Default Value Description
( log4j.configurationFile)
LOG4J_CONFIGURATION_FILE Path to an Log4j 2 configuration file. May also contain a comma separated list of configuration file names. May contain a URL. When specified as a URL the «override» query parameter may be used to specify additional configuration file locations.
( log4j2.debug)
LOG4J_DEBUG Log4j2 will print all internal logging to the console if system property log4j2.debug is defined (with any or no value).
( log4j.mergeStrategy)
LOG4J_MERGE_STRATEGY The name of the class that implements the MergeStrategy interface. If not specified DefaultMergeStrategy will be used when creating a CompositeConfiguration..
( Log4jContextSelector)
LOG4J_CONTEXT_SELECTOR ClassLoaderContextSelector Creates the LoggerContexts. An application can have one or more active LoggerContexts depending on the circumstances. See Log Separation for more details. Available context selector implementation classes:
org.apache.logging.log4j.core.async .AsyncLoggerContextSelector — makes all loggers asynchronous.
org.apache.logging.log4j.core.selector .BasicContextSelector — creates a single shared LoggerContext.
org.apache.logging.log4j.core.selector .ClassLoaderContextSelector — separate LoggerContexts for each web application.
org.apache.logging.log4j.core.selector .JndiContextSelector — use JNDI to locate each web application’s LoggerContext.
org.apache.logging.log4j.core.osgi .BundleContextSelector — separate LoggerContexts for each OSGi bundle.
( Log4jLogEventFactory)
LOG4J_LOG_EVENT_FACTORY org.apache.logging.log4j.core.impl .DefaultLogEventFactory Factory class used by LoggerConfig to create LogEvent instances. (Ignored when the AsyncLoggerContextSelector is used.)
( log4j2.loggerContextFactory)
LOG4J_LOGGER_CONTEXT_FACTORY org.apache.logging.log4j.simple .SimpleLoggerContextFactory Factory class used by LogManager to bootstrap the logging implementation. The core jar provides org.apache.logging.log4j.core .impl.Log4jContextFactory.
( log4j.configurationFactory)
LOG4J_CONFIGURATION_FACTORY Fully specified class name of a class extending org.apache.logging.log4j.core .config.ConfigurationFactory. If specified, an instance of this class is added to the list of configuration factories.
( log4j.shutdownHookEnabled)
LOG4J_SHUTDOWN_HOOK_ENABLED true Overrides the global flag for whether or not a shutdown hook should be used to stop a LoggerContext. By default, this is enabled and can be disabled on a per-configuration basis. When running with the log4j-web module, this is automatically disabled.
( log4j.shutdownCallbackRegistry)
LOG4J_SHUTDOWN_CALLBACK_REGISTRY org.apache.logging.log4j.core.util .DefaultShutdownCallbackRegistry Fully specified class name of a class implementing ShutdownCallbackRegistry. If specified, an instance of this class is used instead of DefaultShutdownCallbackRegistry. The specified class must have a default constructor.
( log4j.Clock)
LOG4J_CLOCK SystemClock Implementation of the org.apache.logging.log4j .core.util.Clock interface that is used for timestamping the log events.
By default, System.currentTimeMillis is called on every log event.
You can also specify a fully qualified class name of a custom class that implements the Clock interface.
( org.apache.logging.log4j.level)
LOG4J_LEVEL ERROR Log level of the default configuration. The default configuration is used if the ConfigurationFactory could not successfully create a configuration (e.g. no log4j2.xml file was found).
LOG4J_DISABLE_THREAD_CONTEXT false If true, the ThreadContext stack and map are disabled. (May be ignored if a custom ThreadContext map is specified.)
LOG4J_DISABLE_THREAD_CONTEXT_STACK false If true, the ThreadContext stack is disabled.
LOG4J_DISABLE_THREAD_CONTEXT_MAP false If true, the ThreadContext map is disabled. (May be ignored if a custom ThreadContext map is specified.)
LOG4J_THREAD_CONTEXT_MAP Fully specified class name of a custom ThreadContextMap implementation class.
LOG4J_IS_THREAD_CONTEXT_MAP_INHERITABLE false If true use a InheritableThreadLocal to implement the ThreadContext map. Otherwise, use a plain ThreadLocal. (May be ignored if a custom ThreadContext map is specified.)
( log4j2.ContextDataInjector)
LOG4J_CONTEXT_DATA_INJECTOR Fully specified class name of a custom ContextDataInjector implementation class.
( log4j2.garbagefree.threadContextMap)
LOG4J_GARBAGEFREE_THREAD_CONTEXT_MAP false Specify «true» to make the ThreadContext map garbage-free.
( log4j2.disable.jmx)
LOG4J_DISABLE_JMX false If true, Log4j configuration objects like LoggerContexts, Appenders, Loggers, etc. will not be instrumented with MBeans and cannot be remotely monitored and managed.
( log4j2.jmx.notify.async)
LOG4J_JMX_NOTIFY_ASYNC false for web apps, true otherwise If true, log4j’s JMX notifications are sent from a separate background thread, otherwise they are sent from the caller thread. If system property log4j2.is.webapp is true or the javax.servlet.Servlet class is on the classpath, the default behaviour is to use the caller thread to send JMX notifications.
( log4j.skipJansi)
LOG4J_SKIP_JANSI true If true, the ConsoleAppender will not try to use the Jansi output stream on Windows.
( log4j.ignoreTCL)
LOG4J_IGNORE_TCL false If true, classes are only loaded with the default class loader. Otherwise, an attempt is made to load classes with the current thread’s context class loader before falling back to the default class loader.
( org.apache.logging.log4j.uuidSequence)
LOG4J_UUID_SEQUENCE System property that may be used to seed the UUID generation with an integer value.
( org.apache.logging.log4j .simplelog.showContextMap)
LOG4J_SIMPLELOG_SHOW_CONTEXT_MAP false If true, the full ThreadContext map is included in each SimpleLogger log message.
( org.apache.logging.log4j .simplelog.showlogname)
LOG4J_SIMPLELOG_SHOWLOGNAME false If true, the logger name is included in each SimpleLogger log message.
( org.apache.logging.log4j .simplelog.showShortLogname)
LOG4J_SIMPLELOG_SHOW_SHORT_LOGNAME true If true, only the last component of a logger name is included in SimpleLogger log messages. (E.g., if the logger name is «mycompany.myproject.mycomponent», only «mycomponent» is logged.
( org.apache.logging.log4j .simplelog.showdatetime)
LOG4J_SIMPLELOG_SHOWDATETIME false If true, SimpleLogger log messages contain timestamp information.
( org.apache.logging.log4j .simplelog.dateTimeFormat)
LOG4J_SIMPLELOG_DATE_TIME_FORMAT «yyyy/MM/dd HH:mm:ss:SSS zzz» Date-time format to use. Ignored if org.apache.logging.log4j .simplelog.showdatetime is false.
( org.apache.logging.log4j .simplelog.logFile)
LOG4J_SIMPLELOG_LOG_FILE system.err «system.err» (case-insensitive) logs to System.err, «system.out» (case-insensitive) logs to System.out, any other value is interpreted as a file name to save SimpleLogger messages to.
( org.apache.logging.log4j .simplelog.level)
LOG4J_SIMPLELOG_LEVEL ERROR Default level for new SimpleLogger instances.
log4j2.simplelog. .level
( org.apache.logging.log4j .simplelog. .level)
LOG4J_SIMPLELOG_ _LEVEL SimpleLogger default log level Log level for a the SimpleLogger instance with the specified name.
( org.apache.logging.log4j.simplelog .StatusLogger.level)
LOG4J_SIMPLELOG_STATUS_LOGGER_LEVEL ERROR This property is used to control the initial StatusLogger level, and can be overridden in code by calling StatusLogger.getLogger() .setLevel(someLevel). Note that the StatusLogger level is only used to determine the status log output level until a listener is registered. In practice, a listener is registered when a configuration is found, and from that point onwards, status messages are only sent to the listeners (depending on their statusLevel).
( Log4jDefaultStatusLevel)
( log4j2.StatusLogger.level)
( log4j2.status.entries)
LOG4J_STATUS_ENTRIES 200 Number of StatusLogger events that are kept in a buffer and can be retrieved with StatusLogger.getStatusData().
( log4j2.StatusLogger.DateFormat)
LOG4J_STATUS_LOGGER_DATEFORMAT Date-time format string to use as the format for timestamps in the status logger output. See java.text.SimpleDateFormat for supported formats.
( AsyncLogger.ExceptionHandler)
LOG4J_ASYNC_LOGGER_EXCEPTION_HANDLER default handler See Async Logger System Properties for details.
( AsyncLogger.RingBufferSize)
LOG4J_ASYNC_LOGGER_RING_BUFFER_SIZE 256 * 1024 or 4 * 1024 in garbage-free mode See Async Logger System Properties for details.
( AsyncLogger.WaitStrategy)
LOG4J_ASYNC_LOGGER_WAIT_STRATEGY Timeout See Async Logger System Properties for details.
( AsyncLogger.Timeout)
LOG4J_ASYNC_LOGGER_TIMEOUT 10 See Async Logger System Properties for details.
( AsyncLogger.SleepTimeNs)
LOG4J_ASYNC_LOGGER_SLEEP_TIME_NS 100 See Async Logger System Properties for details.
( AsyncLogger.Retries)
LOG4J_ASYNC_LOGGER_SLEEP_TIME_NS 200 See Async Logger System Properties for details.
AsyncLogger.SynchronizeEnqueueWhenQueueFull ASYNC_LOGGER_SYNCHRONIZE_ENQUEUE_WHEN_QUEUE_FULL true See Async Logger System Properties for details.
( AsyncLogger.ThreadNameStrategy)
LOG4J_ASYNC_LOGGER_THREAD_NAME_STRATEGY CACHED See Async Logger System Properties for details.
( AsyncLoggerConfig.ExceptionHandler)
LOG4J_ASYNC_LOGGER_CONFIG_EXCEPTION_HANDLER default handler See Mixed Async/Synchronous Logger System Properties for details.
( AsyncLoggerConfig.RingBufferSize)
LOG4J_ASYNC_LOGGER_CONFIG_RING_BUFFER_SIZE 256 * 1024 or 4 * 1024 in garbage-free mode See Mixed Async/Synchronous Logger System Properties for details.
( AsyncLoggerConfig.WaitStrategy)
LOG4J_ASYNC_LOGGER_CONFIG_WAIT_STRATEGY Timeout See Mixed Async/Synchronous Logger System Properties for details.
AsyncLoggerConfig.SynchronizeEnqueueWhenQueueFull ASYNC_LOGGER_CONFIG_SYNCHRONIZE_ENQUEUE_WHEN_QUEUE_FULL true See Mixed Async/Synchronous Logger System Properties for details.
( log4j.jul.LoggerAdapter)
LOG4J_JUL_LOGGER_ADAPTER org.apache.logging.log4j .jul.ApiLoggerAdapter Default LoggerAdapter to use in the JUL adapter. By default, if log4j-core is available, then the class org.apache.logging.log4j.jul .CoreLoggerAdapter will be used. Otherwise, the ApiLogggerAdapter will be used. Custom implementations must provide a public default constructor.
( log4j.format.msg.async)
LOG4J_FORMAT_MSG_ASYNC false If false (the default), Log4j will make sure the message is formatted in the caller thread, to ensure the value at the time of the call to the logger is the value that is logged.
( log4j2.AsyncQueueFullPolicy)
( log4j2.DiscardThreshold)
LOG4J_DISCARD_THRESHOLD INFO Used by the DiscardingAsyncQueueFullPolicy to determine which events to drop when the queue becomes full. By default, INFO, DEBUG and TRACE level events are discarded when the queue is full. This property only has effect if Discard is specified as the log4j2.AsyncQueueFullPolicy.
( log4j2.messageFactory)
LOG4J_MESSAGE_FACTORY org.apache.logging.log4j.message. ParameterizedMessageFactory or org.apache.logging.log4j.message. ReusableMessageFactory in garbage-free mode Default message factory used by Loggers if no factory was specified.
( log4j2.flowMessageFactory)
LOG4J_FLOW_MESSAGE_FACTORY org.apache.logging.log4j.message. DefaultFlowMessageFactory Default flow message factory used by Loggers.
( log4j2.is.webapp)
LOG4J_IS_WEBAPP true if Servlet class on class path This system property can be used to force Log4j 2 to behave as if it is part of a web application (when true) or as if it is not part of a web application (when false).
( log4j2.enable.threadlocals)
LOG4J_ENABLE_THREADLOCALS true This system property can be used to switch off the use of threadlocals, which will partly disable Log4j’s garbage-free behaviour: to be fully garbage-free, Log4j stores objects in ThreadLocal fields to reuse them, otherwise new objects are created for each log event. Note that this property is not effective when Log4j detects it is running in a web application.
( log4j2.enable.direct.encoders)
LOG4J_ENABLE_DIRECT_ENCODERS true This property can be used to force garbage-aware Layouts and Appenders to revert to the pre-2.6 behaviour where converting log events to text generates temporary objects like Strings and char[] arrays, and converting this text to bytes generates temporary byte[] arrays. By default, this property is true and garbage-aware Layouts and Appenders that convert log events to text will convert this text to bytes without creating temporary objects.
( log4j.initialReusableMsgSize)
LOG4J_INITIAL_REUSABLE_MSG_SIZE 128 In GC-free mode, this property determines the initial size of the reusable StringBuilders where the message text is formatted and potentially passed to background threads.
( log4j.maxReusableMsgSize)
LOG4J_MAX_REUSABLE_MSG_SIZE 518 In GC-free mode, this property determines the maximum size of the reusable StringBuilders where the message text is formatted and potentially passed to background threads.
( log4j.layoutStringBuilder.maxSize)
LOG4J_LAYOUT_STRING_BUILDER_MAX_SIZE 2048 This property determines the maximum size of the thread-local reusable StringBuilders used to format the log event to text by Layouts that extend AbstractStringLayout.
( log4j.unbox.ringbuffer.size)
LOG4J_UNBOX_RINGBUFFER_SIZE 32 The org.apache.logging.log4j.util.Unbox utility manages a small thread-local ring buffer of StringBuilders. Each time one of the box() methods is called, the next slot in the ring buffer is used, until the ring buffer is full and the first slot is reused. By default the Unbox ring buffer has 32 slots, so user code can have up to 32 boxed primitives in a single logger call.

If more slots are required, set system property log4j.unbox.ringbuffer.size to the desired ring buffer size. Note that the specified number will be rounded up to the nearest power of 2.

( log4j.LoggerContext.stacktrace.on.start)
LOG4J_LOGGER_CONTEXT_STACKTRACE_ON_START false Prints a stacktrace to the status logger at DEBUG level when the LoggerContext is started. For debug purposes.
( log4j2.formatMsgNoLookups)
FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS false Disables message pattern lookups globally when set to true. This is equivalent to defining all message patterns using %m.
log4j2.trustStoreLocation LOG4J_TRUST_STORE_LOCATION The location of the trust store. If not provided the default trust store will be used.
log4j2.trustStorePassword LOG4J_TRUST_STORE_PASSWORD Password needed to access the trust store.
log4j2.trustStorePasswordFile LOG4J_TRUST_STORE_PASSWORD_FILE The location of a file that contains the password for the trust store.
log4j2.trustStorePasswordEnvironmentVariable LOG4J_TRUST_STORE_PASSWORD_ENVIRONMENT_VARIABLE The name of the environment variable that contains the trust store password.
log4j2.trustStoreType LOG4J_TRUST_STORE_TYPE The type of key store used for the trust store.
log4j2.trustStoreKeyManagerFactoryAlgorithm LOG4J_TRUST_STORE_KEY_MANAGER_FACTORY_ALGORITHM Java cryptographic algorithm.
log4j2.keyStoreLocation LOG4J_KEY_STORE_LOCATION The location of the key store. If not provided the default key store will be used.
log4j2.keyStorePassword LOG4J_KEY_STORE_PASSWORD Password needed to access the key store.
log4j2.keyStorePasswordFile LOG4J_KEY_STORE_PASSWORD_FILE The location of a file that contains the password for the key store.
log4j2.keyStorePasswordEnvironmentVariable LOG4J_KEY_STORE_PASSWORD_ENVIRONMENT_VARIABLE The name of the environment variable that contains the key store password.
log4j2.keyStoreType LOG4J_KEY_STORE_TYPE The type of key store.
log4j2.keyStoreKeyManagerFactoryAlgorithm LOG4J_KEY_STORE_KEY_MANAGER_FACTORY_ALGORITHM Java cryptographic algorithm.
log4j2.sslVerifyHostName false true or false if the host name should be verified

Copyright © 1999-2020 The Apache Software Foundation. All Rights Reserved.
Apache Logging, Apache Log4j, Log4j, Apache, the Apache feather logo, and the Apache Logging project logo are trademarks of The Apache Software Foundation.


Читайте также:  Настройка домена на другом хостинге