[
https://issues.apache.org/jira/browse/LOG4J2-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346409#comment-14346409
]
IngyHere commented on LOG4J2-970:
---------------------------------
Log Snippet ...
{code}
2015-02-01 14:18:52,793 DEBUG Calling build() on class class
org.apache.logging.log4j.core.layout.PatternLayout$Builder for element
PatternLayout with params(pattern="%d{ISO8601} MyFollyApplicationName
dd61:0:0:0:b64a:76dd:df41:d5ef%3 [%-10.10t] %-5.5p %40.40c - %m%n",
Configuration(AGoodConfigName), null, charset="UTF-8",
alwaysWriteExceptions="null", noConsoleNoAnsi="null", header="null",
footer="null")
2015-02-01 14:18:52,793 DEBUG PluginManager 'Converter' found 33 plugins
2015-02-01 14:18:52,801 ERROR Unrecognized format specifier []
2015-02-01 14:18:52,801 ERROR Empty conversion specifier starting at position
58 in conversion pattern.
2015-02-01 14:18:52,804 DEBUG Built Plugin[name=layout] OK from builder factory
method.
{code}
Note the weirdly formed IPv6 address with the "%3" appended:
"dd61:0:0:0:b64a:76dd:df41:d5ef%3".
The actual pattern is ...
{code}
"%d{ISO8601} ${sys:anAppName} ${map:hostName} [%-10.10t] %-5.5p %40.40c - %m%n"
{code}
Also, FYI, this is being configured using a JSON file.
> Bad Mapped Hostname Results in Errors
> -------------------------------------
>
> Key: LOG4J2-970
> URL: https://issues.apache.org/jira/browse/LOG4J2-970
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Pattern Converters
> Affects Versions: 2.1
> Reporter: IngyHere
>
> Log4J returns errors while parsing PatternLayout in certain situations where
> ${map:hostName} is substituted into the pattern. This occurred on a
> dual-homed Linux System with an IPv4/IPv6 dual stack. When running Java 7u60
> with Log4J2 v2.1 I received errors when the hostname call reported back an
> IPv6 transitional address with "%3" appended to the end for whatever reason.
> Log4J2 then reported errors when it tried to parse the resulting pattern
> after substituting the property.
> Explanation: The underlying Java API that retrieves hostname values uses the
> InetAddress class via InetAddress.getLocalHost().getHostName(). Returning a
> single hostname on a multihomed system is inexact and uses one of several
> Java API internal mechanisms that vary. If the returned value contains
> special characters also used to format logging patterns, it can cause an
> unrecognized format specifier error. Note that there are several bugs
> reported against this API at Oracle, see
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8044306 .
> Detail: See
> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
> on line 45 where it collects the information.
> Proposed Fix: Scrub the hostName property (probably a few other properties,
> too) of any protected or special symbols that are interpreted by Log4J to
> output conversions. I'm also considering a situation where a hostname can be
> illegally specified in a hosts file to contain conversions -- can this
> happen?
> NOTE: Log4J2 outputs errors about parsing the pattern but continues to parse
> the remainder of the pattern and appears to continue logging successfully.
> See attached log snippets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
