[
https://issues.apache.org/jira/browse/LOG4J2-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652899#comment-13652899
]
Nick Williams commented on LOG4J2-245:
--------------------------------------
You are paranoid :-) ... and slightly incorrect:
1) The way the Stack is created and used here, it is on the Java stack during
the execution of the constructor, it is local, it is not held by any other
objects, and it cannot be concurrently modified. So there is no danger of
stack.pop() throwing another ESE if class != null.
2) If the Stack WERE a reference shared by other objects (it is not, to be
clear), calling stack.isEmpty() again STILL would not guard against an ESE. You
would need to synchronize access to the stack to prevent this completely.
However, since it's only local, you don't need to synchronize.
Also, that was a good hypothesis, but it did not hold. The reason JMX was being
used is that IntelliJ deploys projects using JMX. So I deployed the project and
started Tomcat manually, instead, which removed JMX from the equation. Stack
trace is different, problem still exists.
Nick
SEVERE: Exception sending context initialized event to listener instance of
class org.springframework.web.context.ContextLoaderListener
java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:102)
at
org.apache.logging.log4j.core.impl.ThrowableProxy.resolvePackageData(ThrowableProxy.java:339)
at
org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:71)
at
org.apache.logging.log4j.core.impl.Log4jLogEvent.<init>(Log4jLogEvent.java:110)
at
org.apache.logging.log4j.core.impl.Log4jLogEvent.<init>(Log4jLogEvent.java:81)
at
org.apache.logging.log4j.core.config.LoggerConfig.createEvent(LoggerConfig.java:423)
at
org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:344)
at org.apache.logging.log4j.core.Logger.log(Logger.java:110)
at
org.apache.logging.log4j.spi.AbstractLoggerWrapper.log(AbstractLoggerWrapper.java:55)
at
org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:539)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:319)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1056)
at
org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1610)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
> EmptyStackException when logging error through JCL bridge
> ---------------------------------------------------------
>
> Key: LOG4J2-245
> URL: https://issues.apache.org/jira/browse/LOG4J2-245
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, JCL Bridge
> Affects Versions: 2.0-beta5, 2.0-beta6
> Reporter: Nick Williams
> Priority: Blocker
>
> Possibly affects earlier versions, too, but I did not check.
> beta5 and beta6 are both unusable with Spring Framework. Any time an error
> gets logged through log4j-jcl bridge using Spring, the error below appears in
> the Tomcat log, masking the error that Spring was trying to log and making it
> very difficult to figure out what happened. I've also included my
> configuration file below the stack trace. The root error is happening on
> Tomcat 6 due to Spring bug, and that root problem is unimportant. The
> important problem is the Log4j error that masks it.
> SEVERE: Exception sending context initialized event to listener instance of
> class org.springframework.web.context.ContextLoaderListener
> java.util.EmptyStackException
> at java.util.Stack.peek(Stack.java:102)
> at
> org.apache.logging.log4j.core.impl.ThrowableProxy.resolvePackageData(ThrowableProxy.java:339)
> at
> org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.<init>(Log4jLogEvent.java:110)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.<init>(Log4jLogEvent.java:81)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.createEvent(LoggerConfig.java:423)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:344)
> at org.apache.logging.log4j.core.Logger.log(Logger.java:110)
> at
> org.apache.logging.log4j.spi.AbstractLoggerWrapper.log(AbstractLoggerWrapper.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:539)
> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:319)
> at
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
> at
> org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1491)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> at
> org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:468)
> at
> org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:415)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1465)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:75)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1306)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1398)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:491)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration status="WARN">
> <appenders>
> <Console name="Console" target="SYSTEM_OUT">
> <PatternLayout
> pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
> %msg%n"/>
> </Console>
> <RollingFile name="WroxFileAppender"
> fileName="../logs/application.log"
> filePattern="../logs/application-%d{MM-dd-yyyy}-%i.log">
> <PatternLayout>
> <pattern>%d{HH:mm:ss.SSS} [%t] %X{id} %X{username} %-5level
> %c{36} %l: %msg%n</pattern>
> </PatternLayout>
> <Policies>
> <SizeBasedTriggeringPolicy size="10 MB" />
> </Policies>
> <DefaultRolloverStrategy min="1" max="4" />
> </RollingFile>
> </appenders>
> <loggers>
> <root level="warn">
> <appender-ref ref="Console" />
> <appender-ref ref="WroxFileAppender" />
> </root>
> <logger name="com.wrox" level="info" />
> <logger name="org.apache" level="info" />
> <logger name="org.springframework" level="info" />
> </loggers>
> </configuration>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
