[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756503#comment-13756503
]
Neale Upstone edited comment on LOG4J2-293 at 9/3/13 10:54 AM:
---------------------------------------------------------------
Okay. More time spent with a debugger to find:
- classpath:/properties/log4j2.xml still *fails silently* (this should at least
output something saying that nothing was found, or preferably illegal config
and bomb out)
- classpath:properties/log4j2.xml works (once I've excluded an old Xerces 2.6
from my build).
- when running, there is lots of "WARN locateContext called with URI null.
Existing LoggerContext has URI classpath:properties/dev/log4j2.xml". I think
being called with null is to be expected, as that's what lots of filters etc
are doing via things like commons logging or SLF4J APIs.
The silent failure is still a bug. I should not need to use a debugger, and it
certainly should be covered in the documentation (and isn't. An example for
classpath: is needed).
I'd even suggest that the JavaDoc for Log4jServletContextListener could say
what params it expects and what the valid values are.
If you want to help those who somehow have Xerces 2.6.1 or equiv on their
classpath, then the following could be caught and dealt with (e.g. continue,
but warn that they have old XML parser around):
{code}
java.lang.AbstractMethodError:
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at
org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:106)
{code}
was (Author: nealeu):
Okay. More time spent with a debugger to find:
- classpath:/properties/log4j2.xml still *fails silently* (this should at least
output something saying that nothing was found, or preferably illegal config
and bomb out)
- classpath:properties/log4j2.xml works (once I've excluded an old Xerces 2.6
from my build).
- when running, there is lots of"WARN locateContext called with URI null.
Existing LoggerContext has URI classpath:properties/dev/log4j2.xml". I think
being called with null is to be expected, as that's what lots of filters etc
are doing via things like commons logging or SLF4J APIs.
The silent failure is still a bug. I should not need to use a debugger, and it
certainly should be covered in the documentation (and isn't. An example for
classpath: is needed).
I'd even suggest that the JavaDoc for Log4jServletContextListener could say
what params it expects and what the valid values are.
If you want to help those who somehow have Xerces 2.6.1 or equiv on their
classpath, then the following could be caught and dealt with (e.g. continue,
but warn that they have old XML parser around):
{code}
java.lang.AbstractMethodError:
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at
org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:106)
{code}
> 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
> Fix For: 2.0-beta9
>
> Attachments: ConfigurationFactory.java, LOG4J2-293.patch,
> TestConfigurator.java
>
>
> 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
