[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727527#comment-13727527
]
Neale Upstone edited comment on LOG4J2-293 at 8/2/13 10:15 AM:
---------------------------------------------------------------
I've got further on this. I think that some helpful checking could be done.
What seems to be happening is:
- web.xml has other listeners. log4j2 is the first listed, but the other fires
first (This seems a Tomcat 7 issue:
http://tomcat.10.x6.nabble.com/Autowired-spring-bean-not-working-in-tomcat-7-0-35-with-jax-ws-td4993897.html)
- The other listener calls SLF4J Log4jLoggerFactory.getLogger(), which in turn
calls Log4jContextFactory.getContext()
- This causes a LoggerContext to be created with configLocation set to null
(ClassLoaderContextSelector:line 204). This is placed in CONTEXT_MAP.
- After the above, the Log4jServletContextListener fires.
- locateContext() is called again, this time with the URI set. At line 214
({{if(ctx != null) return ctx;}}), you now have ctx.configLocation==null, but
the passed in configLocation is classloader:/path/to/log4j2.xml
Should the key used for CONTEXT_MAP perhaps contain configLocation too?
I think at the very least, a useful warning could be emitted when the
configLocation mis-match is discovered. I would have thought the expected
behaviour would be that a reconfiguration would take place at this point, so
Log4j2 would tolerate the late config. I've always thought that this is what's
been happening with 1.2.x.
was (Author: nealeu):
I've got further on this. I think that some helpful checking could be
done. What seems to be happening is:
- web.xml has other listeners. log4j2 is the first listed, but the other fires
first. The other listener calls SLF4J Log4jLoggerFactory.getLogger(), which in
turn calls Log4jContextFactory.getContext()
- This causes a LoggerContext to be created with configLocation set to null
(ClassLoaderContextSelector:line 204). This is placed in CONTEXT_MAP.
- After the above, the Log4jServletContextListener fires.
- locateContext() is called again, this time with the URI set. At line 214
({{if(ctx != null) return ctx;}}), you now have ctx.configLocation==null, but
the passed in configLocation is classloader:/path/to/log4j2.xml
Should the key used for CONTEXT_MAP perhaps contain configLocation too?
> classloader URI scheme broken or insufficient when using Log4jContextListener
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-293
> URL: https://issues.apache.org/jira/browse/LOG4J2-293
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Affects Versions: 2.0-beta7
> Reporter: Neale Upstone
> Assignee: Nick Williams
> Labels: documentation
>
> I'm trying to migrate to Log4j2, and things looked promising when I spotted
> Log4jContextListener.
> However, there are too many holes.
> Firstly, I tried using classpath: as a scheme, and nothing blew up, so I
> assumed I'd got it right.
> Then I *looked at the code* (which shouldn't be how we find out) and
> eventually discovered some code relating to a 'classloader' scheme.
> Still silent failure. It seems that the classpath is not being searched,
> perhaps just the WAR classloader, not the JARs in WEB-INF/lib.
> Next I tried omitting the / (i.e. using classloader:log4j2.xml) and got a
> NullPointerException.
> Can you please document what schemes are supported and what you expect them
> to do, and *not fail silently* when a configuration file is specified, but
> nothing happens.
--
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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
