[
https://issues.apache.org/jira/browse/LOG4J2-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-919:
--------------------------------
Description:
I have a setup that involves Tomcat 7 running under JDK6 which has been using
lgo4j 2 since around beta3 or so. After a recent upgrade attempt I was left
with a system that basically had no logging at all.
I started back at beta6 (my last known working version) and upgraded one
release at a time until it finally broke at beta9. I got the source code for
this version and spent a considerable amount of time running Tomcat under a
debugger and tracing it down to an exception that occurs during initialization
of the XML config.
The actual exception, however, is not caught and then subsequently lost higher
up in the stack! And, to make matters worse, it never gets to the point of
creating the StatusLogger, so I can't get any help from that kind of trace
output. So as a result, it just silently fails, and reverts back to the
default configuration of ERROR to Console only with no internal log messages.
After narrowing down to where the exception occurs, it seems to have been
introduced in beta9 by LOG4J2-341 which adds XInclude support. The offending
line is in XMLconfiguration.enableXInclude(...) where it calls
factory.setXIncludeAware(true). I was unable to get the actual exception
itself, but I think it was a NoSuchMethodError. Using debug watches I
painstakingly constructed this stack trace (line #s are based on beta9 code):
{noformat}
org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:110)
org.apache.logging.log4j.core.config.XMLConfiguration.newDocumentBuilder(XMLConfiguration.java:97)
org.apache.logging.log4j.core.config.XMLConfiguration.<init>(XMLConfiguration.java:146)
org.apache.logging.log4j.core.config.XMLConfigurationFactory.getConfiguration(XMLConfigurationFactory.java:40)
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:446)
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:420)
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:377)
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:61)
org.apache.log4j.Logger.getLogger(Logger.java:39)
[snip for brevity]
{noformat}
This call is wrapped in a try/catch, but only catches these exceptions:
UnsupportedOperationException
AbstractMethodError
I compared each version after that, and the code for this method hasn't really
changed much (some revisions in 2.0-rc2 I believe) so that would be why the
issue persists in 2.1 still.
I have a feeling the javax.xml.* libraries on my system are outdated, and will
look into that further. But in the meantime I figured I would report this
not-graceful-at-all handling of the situation where XInclude is not supported
by the system. Hopefully this is enough detail for someone to be able to
reproduce & fix the problem.
was:
I have a setup that involves Tomcat 7 running under JDK6 which has been using
lgo4j 2 since around beta3 or so. After a recent upgrade attempt I was left
with a system that basically had no logging at all.
I started back at beta6 (my last known working version) and upgraded one
release at a time until it finally broke at beta9. I got the source code for
this version and spent a considerable amount of time running Tomcat under a
debugger and tracing it down to an exception that occurs during initialization
of the XML config.
The actual exception, however, is not caught and then subsequently lost higher
up in the stack! And, to make matters worse, it never gets to the point of
creating the StatusLogger, so I can't get any help from that kind of trace
output. So as a result, it just silently fails, and reverts back to the
default configuration of ERROR to Console only with no internal log messages.
After narrowing down to where the exception occurs, it seems to have been
introduced in beta9 by LOG4J2-341 which adds XInclude support. The offending
line is in XMLconfiguration.enableXInclude(...) where it calls
factory.setXIncludeAware(true). I was unable to get the actual exception
itself, but I think it was a NoSuchMethodError. Using debug watches I
painstakingly constructed this stack trace (line #s are based on beta9 code):
org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:110)
org.apache.logging.log4j.core.config.XMLConfiguration.newDocumentBuilder(XMLConfiguration.java:97)
org.apache.logging.log4j.core.config.XMLConfiguration.<init>(XMLConfiguration.java:146)
org.apache.logging.log4j.core.config.XMLConfigurationFactory.getConfiguration(XMLConfigurationFactory.java:40)
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:446)
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:420)
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:377)
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:61)
org.apache.log4j.Logger.getLogger(Logger.java:39)
[snip for brevity]
This call is wrapped in a try/catch, but only catches these exceptions:
UnsupportedOperationException
AbstractMethodError
I compared each version after that, and the code for this method hasn't really
changed much (some revisions in 2.0-rc2 I believe) so that would be why the
issue persists in 2.1 still.
I have a feeling the javax.xml.* libraries on my system are outdated, and will
look into that further. But in the meantime I figured I would report this
not-graceful-at-all handling of the situation where XInclude is not supported
by the system. Hopefully this is enough detail for someone to be able to
reproduce & fix the problem.
> Logging system fails to initialize if XInclude is not available
> ---------------------------------------------------------------
>
> Key: LOG4J2-919
> URL: https://issues.apache.org/jira/browse/LOG4J2-919
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta9, 2.0-rc1, 2.0-rc2, 2.0, 2.0.1, 2.0.2, 2.1
> Environment: Linux x86_64, JDK 1.6.x
> Reporter: David Johle
> Assignee: Gary Gregory
> Priority: Minor
> Labels: config, initialization, xml
> Fix For: 2.2
>
>
> I have a setup that involves Tomcat 7 running under JDK6 which has been using
> lgo4j 2 since around beta3 or so. After a recent upgrade attempt I was left
> with a system that basically had no logging at all.
> I started back at beta6 (my last known working version) and upgraded one
> release at a time until it finally broke at beta9. I got the source code for
> this version and spent a considerable amount of time running Tomcat under a
> debugger and tracing it down to an exception that occurs during
> initialization of the XML config.
> The actual exception, however, is not caught and then subsequently lost
> higher up in the stack! And, to make matters worse, it never gets to the
> point of creating the StatusLogger, so I can't get any help from that kind of
> trace output. So as a result, it just silently fails, and reverts back to
> the default configuration of ERROR to Console only with no internal log
> messages.
> After narrowing down to where the exception occurs, it seems to have been
> introduced in beta9 by LOG4J2-341 which adds XInclude support. The offending
> line is in XMLconfiguration.enableXInclude(...) where it calls
> factory.setXIncludeAware(true). I was unable to get the actual exception
> itself, but I think it was a NoSuchMethodError. Using debug watches I
> painstakingly constructed this stack trace (line #s are based on beta9 code):
> {noformat}
> org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:110)
> org.apache.logging.log4j.core.config.XMLConfiguration.newDocumentBuilder(XMLConfiguration.java:97)
> org.apache.logging.log4j.core.config.XMLConfiguration.<init>(XMLConfiguration.java:146)
> org.apache.logging.log4j.core.config.XMLConfigurationFactory.getConfiguration(XMLConfigurationFactory.java:40)
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:446)
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:420)
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:377)
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:200)
> org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:61)
> org.apache.log4j.Logger.getLogger(Logger.java:39)
> [snip for brevity]
> {noformat}
> This call is wrapped in a try/catch, but only catches these exceptions:
> UnsupportedOperationException
> AbstractMethodError
> I compared each version after that, and the code for this method hasn't
> really changed much (some revisions in 2.0-rc2 I believe) so that would be
> why the issue persists in 2.1 still.
> I have a feeling the javax.xml.* libraries on my system are outdated, and
> will look into that further. But in the meantime I figured I would report
> this not-graceful-at-all handling of the situation where XInclude is not
> supported by the system. Hopefully this is enough detail for someone to be
> able to reproduce & fix the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
