I'm not sure why event.getLevel() was null but the workaround works for me.

Full stacktrace:
2013-12-05 09:36:58,947 ERROR An exception occurred processing Appender MySizeRollingLog java.lang.NullPointerException
at org.apache.logging.log4j.core.pattern.LevelPatternConverter.format(LevelPatternConverter.java:122)
at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:36)
at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:167)
at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:52)
at org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:45)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:111)
at org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:96)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:99)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425)
at org.apache.logging.log4j.core.async.AsyncLoggerConfig.asyncCallAppenders(AsyncLoggerConfig.java:116)
at org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigHelper.java:218)
at org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigHelper.java:203)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:133)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)

Remko Popma
added a comment - 12/Dec/13 01:52 Thanks for reporting this.
I'm very surprised that event.getLevel() returns null . I think that should never happen. (Team: am I right? Or are there cases where event.getLevel() is legitimately null?)
Daisuke, can you also post your code where you programmatically configure log4j?

Indeed, what I did seems to be a little bit tricky. Let me explain.
I'm running my app on the Tomcat7. And I wrote a class to initialize Log4J2 with a specified file within ServletContextListener#contextInitialized().
In the Log4J2 initialization class, I wrote the code like this:

Daisuke Baba
added a comment - 12/Dec/13 09:31 Indeed, what I did seems to be a little bit tricky. Let me explain.
I'm running my app on the Tomcat7. And I wrote a class to initialize Log4J2 with a specified file within ServletContextListener#contextInitialized().
In the Log4J2 initialization class, I wrote the code like this:
// context => a ServletContext object
String log4j2File = context.getInitParameter( "..." );
final URI log4j2FileURI = log4j2File.toURI();
LoggerContext ctx = (LoggerContext) LogManager.getContext( false );
ctx.setConfigLocation(log4j2FileURI);
ctx.reconfigure();
Note that I used reflection in order to manipulate org.apache.logging.log4j.* classes because I'd like to inject the log4j2 dependency dynamically rather than statically for our specific reason.
I'm also enabling asynchronous logging by providing -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector option to the Tomcat startup shell.
SLF4J is also included in my app. So I import the following library as well.
<dependency>
<groupId> org.apache.logging.log4j </groupId>
<artifactId> log4j-slf4j-impl </artifactId>
<version> 2.0-beta9 </version>
<scope> runtime </scope>
</dependency>

Daisuke, both this issue and LOG4J2-465 occur because somehow the LogEventLevel became null.

I thought this wasn't possible but I missed an obvious way this can happen. The Logger interface has about 14 log methods, 2 printf methods and a throwing that take a Level parameter. Is it possible that your application calls one of these methods with a nullLevel parameter?

Team, should we replace nullLevel parameters with Level.OFF when constructing a LogEvent to prevent NPEs?
I think that would be preferable to having to check if level == null everywhere downstream...

Remko Popma
added a comment - 03/Jan/14 15:21 Daisuke, both this issue and LOG4J2-465 occur because somehow the LogEvent Level became null .
I thought this wasn't possible but I missed an obvious way this can happen. The Logger interface has about 14 log methods, 2 printf methods and a throwing that take a Level parameter. Is it possible that your application calls one of these methods with a null Level parameter?
Team, should we replace null Level parameters with Level.OFF when constructing a LogEvent to prevent NPEs?
I think that would be preferable to having to check if level == null everywhere downstream...