Ralph Goers | 17 Jul 07:26 2014

[ANNOUNCEMENT] Apache Log4j 2.0 released

The Apache Log4j 2 team is pleased to announce the Log4j 2.0 release!

Apache log4j is a well known framework for logging application behavior. Log4j 2 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

This is the first GA release, after thirteen prior releases over the last 4 years.

GA Release

Changes in this version include:

New features:
o LOG4J2-519:  Added support for generating custom logger wrappers that replace the existing log levels
        and extended logger wrappers that add custom log levels to the existing ones. 
o LOG4J2-696:  RegexFilter does not match multiline log messages. 

Fixed Bugs:
o LOG4J2-705:  Fixed issue where Async Logger does not log thread context stack data.
        API change: added method getImmutableStackOrNull() to ThreadContext.ContextStack interface. 
o LOG4J2-631:  Update docs to clarify how to use formatter logger and standard logger together. 
o LOG4J2-441:  LoggerConfigs with no Level now inherit the Level from their parent. 
o LOG4J2-703:  Android: Could not find class 'javax.naming.InitialContext', referenced from method
org.apache.logging.log4j.core.lookup.JndiLookup.lookup. Thanks to Nelson Melina. 
o LOG4J2-699:  PatternLayout manual page missing documentation on header/footer. 
o LOG4J2-625:  Fixed Serialization error with SocketAppender and Async Loggers.
        (Fixed in RC2, but wasn't included in release notes.) 
o LOG4J2-538:  JMX GUI: fixed occasional ArrayIndexOutOfBoundsException after pressing "reconfigure
with XML below".
(Continue reading)

dxande6 | 14 Jul 19:54 2014

Extending Appenders

I've tried extending the appenders with the following code and keep getting

 <at> Plugin(name = "Stub", category = "Core", elementType = "appender",
printObject = true)
2.public final class StubAppender extends OutputStreamAppender {
4.    private StubAppender(String name, Layout layout, Filter filter,
StubManager manager,
5.                         boolean ignoreExceptions) {
6.    }
8.     <at> PluginFactory
9.    public static StubAppender createAppender( <at> PluginAttribute("name")
String name,
 <at> PluginAttribute("ignoreExceptions") boolean ignoreExceptions,
11.                                               <at> PluginElement("Layout")
Layout layout,
12.                                               <at> PluginElement("Filters")
Filter filter) {
14.        if (name == null) {
15.            LOGGER.error("No name provided for StubAppender");
16.            return null;
17.        }
19.        StubManager manager = StubManager.getStubManager(name);
20.        if (manager == null) {
21.            return null;
(Continue reading)

Vishal Pore | 11 Jul 08:01 2014

All log4j appenders defined in log4j.properties in play

My log4j.properties file is pasted below. My understanding is that we need
to add Appenders to the *root *logger for the appender to work. As you can
see in the below properties file, only appender A is attached to the root
logger (log4j.rootLogger=info, A). However, what I see is that the logging
information is printed to both the appenders (ConsoleAppender - A and File
Appender - B). How is this possible?

log4j.rootLogger=info, A
log4j.appender.A.layout.ConversionPattern=%-4r [%t] [rid=%X{RID} ]
%-5p %c %x - %m%n

log4j.appender.B.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

I have posted the same question on


 and failed to get any responses. Any resposes appreciated.


Vishal Pore
guowei | 11 Jul 05:16 2014

log4j.properties gets loaded twice causing rollling to fail

Dear all,

I am using log4j for tomcat internal logging and also application logging.

I followed Tomcat's instruction to configure log4j rolling and I also have configured my application to
have its own log4j rolling.

log4j.jar is in both Tomcat's lib and web application's lib, each have their respective log4j.properties

I enabled -Dlog4j.debug and I can see the sequence of the events

1) log4j.properties for the tomcat gets loaded by Tomcat's StandardClassLoader
2) the same log4j.properties for tomcat gets loaded by the Tomcat's WebappClassLoader
3) application's log4j.properties is loaded

Between 1) and 2) I can see the tomcat files being rolled ( I intentionally set DailyRollingAppender to
yyyy-MM-dd-HH-mm and DEBUG level to make sure lots of things gets logged). Rolling was working well.
Files were rolled on the minute

However, when step 2) kicks in, the rolling of tomcat files failed. 
I reckon that the moment the the same log4j.properties is loaded, there is a conflict since the same
appenders are referred twice.
I am not certain has it anything to do with the tomcat's log4j configuration or appliation's log4j
configuration. The Application's log files are rolled correctly.
Would appreciate if anyone can enlighten me.

-----Dlog4j.debug output----
log4j: Trying to find [log4j.xml] using context classloader org.apache.catalina.loader.StandardClassLoader <at> 1529d183.
log4j: Trying to find [log4j.xml] using org.apache.catalina.loader.StandardClassLoader <at> 1529d183
class loader.
(Continue reading)

Mohammad Arouri | 10 Jul 11:17 2014

Log4j2 Official Release


Can you update me with the release date for log4j2 or at least a guidance
of when you are planning to release.

Mohammad Arouri


Best Regards
Mohammad Arouri

Phil Wray | 24 Jun 16:01 2014

Re: how to change logging level for a class at runtime

Classification: Public

Hi Ralph,
Just to confirm running latest trunk version its possible to change levels 
at runtime using code as per your docs.
Thanks for the help.
I see a tag for 2.0-rc2 was taken a couple of days ago - I'm guessing this 
is being released imminently?

In case it helps others I ended up with the following util to let us 
change levels via jmx, just using whatever existing appender the logger 
would have had.

         <at> ManagedOperation
        public String changeLogLevel(String loggerName, String level){
                Level newLevel = Level.toLevel(level);
                LoggerContext ctx = (LoggerContext) LogManager.getContext(
                Configuration config = ctx.getConfiguration();
                LoggerConfig loggerConfig = 
                String msg;

                if (loggerName.equals(loggerConfig.getName())){
                        Level oldLevel = loggerConfig.getLevel();
                        msg = String.format("Modified existing logger %s 
level from %s to %s", loggerName, oldLevel, newLevel); 
                } else {
                        createCopyFrom(loggerConfig, loggerName, newLevel, 
(Continue reading)

Phil Wray | 24 Jun 12:16 2014

Re: how to change logging level for a class at runtime

Classification: Public

Hi Ralph,
Sorry hadn't looked at the latest source  - see you've made changes to 
Configuration to allow adding of LoggerConfig via the interface that are 
not yet in the release candidate jar.
I'll take the latest source and build from that.


Phil Wray/ext/dbcom
"Log4J Users List" <log4j-user <at> logging.apache.org>, 
24/06/2014 09:07
Re: how to change logging level for a class at runtime

Classification: Public

Hi Ralph,
Thanks for getting back, but the examples do not show how to change levels 
at runtime,

There is no method addLogger(String, LoggerConfig) method on the 
Configuration interface.
The addLogger method exists on BaseConfiguration, however it throws an 
IllegalStateException as its already started, and says you have to create 
(Continue reading)

Phil Wray | 23 Jun 12:44 2014

how to change logging level for a class at runtime

Classification: Public

Would like to turn on debug for a particular class or package at runtime, 
either via jmx or programmatically, where this class or package is 
arbitrary and not known at start up time please.
I can't see a way to do this?
Previous posts titled "Programmatic configuration of loggers" show how to 
do this for an existing named logger but not for an arbitrary class or 
package which is a typical use case.
LoggerConfig loggerConfig = config.getLoggerConfig(loggerName);

But this returns the root logger if no existing logger for that name 
exists - and we can't just enable debug on everything.
Is there a way of adding a new LoggerConfig into the configuration?

Phil Wray


This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and delete this
e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and
regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for
information about privacy.
Petar Tahchiev | 20 Jun 14:28 2014

Appender to support carriage return

Hi guys,

I was wondering if there's a LOG4J console appender out there that supports
a carriage return \r (to put the cursor back on the same line).

Cheers, Petar.


Regards, Petar!
Karlovo, Bulgaria.
Public PGP Key at:
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
Graham Clark | 20 Jun 12:31 2014

Overriding the default log4j.properties


I'm completely new to log4j so please forgive any stupid questions.

I have an application with a log4j.properties file in it which works
normally. I want to override the destination of the log file, though, so
I've created my own log4j.properties file and pointed to it with the
log4j.configuration=file.... JVM property. This works as expected and log4j
initialises and creates a log file in my new directory. This is where it
goes wrong (or at least doesn't do what I expect).

Having started up and created the correct log file, it then goes off and
reads the application's own log4j.properties file and creates another log
file in the old directory (that I don't want to write to). It then uses
this log file (and not the one it created first in my directory) to write
the log messages to. Is this working as expected? How do I stop it looking
at the old properties file and just take notice of what's in my new
properties file?

Here's the debug messages.

log4j: Using URL Ýfile:/u/ssdb008/log4j.properties¨ for automatic log4j
log4j: Reading configuration from URL file:/u/ssdb008/log4j.properties
                                        My PROPERTIES FILE

log4j: Parsing for Ýroot¨ with value=ÝDEBUG¨.

log4j: Level token is ÝDEBUG¨.

(Continue reading)

Dave Kriewall | 17 Jun 22:06 2014

Using JMX to change the log level of a LoggerConfig

I am trying to dynamically change the log level of a given LoggerConfig using jconsole via the JMX
interface.  This is currently possible by going to the org.apache.logging.log4j2.Default.Loggers
tree in jconsole's MBeans pane, choosing the desired logger, and typing a new Level value (such as
"DEBUG") in the "Attribute values" panel.  But it has no effect because LoggerContext.updateLoggers()
is not called.  Is there a way to invoke updateLoggers() via JMX?

If not, could LoggerContextAdmin be enhanced to expose updateLoggers() as an action?  Or better, invoke
updateLoggers() as a side effect of LoggerConfigAdmin.setLevel() -- which saves a step.