[
https://issues.apache.org/jira/browse/LOG4J2-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661621#comment-13661621
]
Nick Williams commented on LOG4J2-223:
--------------------------------------
I think you misunderstood my comment. I'm not suggesting the shutdown hook
should be removed completely. I fully recognize it is needed in standalone
apps. You said, "You are correct that the {{LoggerContext}} adds the shutdown
hook. I suppose the way to deal with that is to add another attribute to the
configuration element to enable the hook." My response was that I don't think
it's a _must_ to add the ability to enable/disable the hook because the
listener and filter take actions that remove the hook.
I think you're wrong about something, though. You said, "With the
{{BasicContextListener}} [I think you meant BasicContextSelector] the behavior
you should get should match Log4j 1.x - it won't shutdown the {{LoggerContext}}
and the appenders, etc. won't be gracefully cleaned up. Adding the context
listener provides that." That is not completely true all the time. Since
{{LoggerContext}} creates a shutdown hook, it _will_ shut down the
{{LoggerContext}} and the appenders if the servlet container is shut down
without undeploying the application. The only time the {{LoggerContext}} and
appenders won't be shut down is if the application is undeployed _before_ the
container is shut down.
Before we start discussing web-fragment.xml, etc., I want to get
{{Log4jContextListener}} and {{JNDIContextFilter}} straight.
- {{Log4jContextListener}} does the following:
-- On startup, it calls {{Configurator.initialize}} which loads the Log4j
configuration and creates the correct selector ({{BasicContextSelector}},
{{ClassLoaderContextSelector}}, {{JNDIContextSelector}}, etc. based on
properties). It then adds the returned {{LoggerContext}} to the
{{ServletContext}} as a context attribute.
-- On shutdown, it calls {{Configurator.shutdown}} which calls {{stop()}} on
the {{LoggerContext}} which, incidentally, results in the shutdown hook being
removed.
- {{JNDIContextFilter}} does the following:
-- On startup, it checks if the servlet context attribute for a
{{LoggerContext}} is set. If it is, it does nothing and the filter essentially
becomes a no-op. It then gets the {{LoggerContextFactory}} from the
{{LogManager}}. _If_ the factory is a {{Log4jContextFactory}} and _if_ its
selector is a {{NamedContextSelector}} (*note: NOT a JNDIContextSelector*), it
adds the {{LoggerContext}} to the {{ServletContext}} as a context attribute.
Otherwise, the filter essentially becomes a no-op.
-- On each request, it looks for the {{LoggerContext}} on the
{{ServletContext}} and sets it to {{ContextAnchor.THREAD_CONTEXT}} if it exists.
-- On shutdown, it stops the {{LoggerContext}} which, incidentally, results in
the shutdown hook being removed.
-- Questions:
--- Why is the {{JNDIContextFilter}} working with the {{NamedContextSelector}}
instead of the {{JNDIContextSelector}} as previously explained?
--- Why does {{JNDIContextFilter}} have to set a thread local in {{doFilter}}?
I don't see how the correct loggers won't be used if the thread local isn't set.
--- Am I correct in assuming that, based on all of this, the
{{JNDIContextFilter}} will not work correctly use the {{NamedContextSelector}}
if the {{Log4jContextListener}} is also in use (as-written), and will (perhaps
incorrectly) add the {{LoggerContext}} created in the {{Log4jContextListener}}
to the thread local if both are used?
> IllegalStateException thrown during Tomcat shutdown
> ---------------------------------------------------
>
> Key: LOG4J2-223
> URL: https://issues.apache.org/jira/browse/LOG4J2-223
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta5
> Reporter: Ralph Goers
> Priority: Critical
> Fix For: 2.0-beta7
>
> Attachments: log4j-223.war
>
>
> {noformat}Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardServer
> await
> INFO: A valid shutdown command was received via the shutdown port. Stopping
> the Server instance.
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol pause
> INFO: Pausing ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.core.StandardService stopInternal
> INFO: Stopping service Catalina
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol stop
> INFO: Stopping ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["http-nio-8080"]
> Apr 25, 2013 3:03:33 PM org.apache.coyote.AbstractProtocol destroy
> INFO: Destroying ProtocolHandler ["ajp-nio-8009"]
> Apr 25, 2013 3:03:33 PM org.apache.catalina.loader.WebappClassLoader loadClass
> INFO: Illegal access: this web application instance has been stopped already.
> Could not load org.apache.logging.log4j.core.config.NullConfiguration. The
> eventual following stack trace is caused by an error thrown for debugging
> purposes as well as to attempt to terminate the thread which caused the
> illegal access, and has no functional impact.
> java.lang.IllegalStateException
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1351)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Exception in thread "Thread-18" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/config/NullConfiguration
> at
> org.apache.logging.log4j.core.LoggerContext.stop(LoggerContext.java:171)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:389)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.config.NullConfiguration
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1465)
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1310)
> ... 2 more{noformat}
--
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]