[
https://issues.apache.org/jira/browse/LOG4J2-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614995#comment-17614995
]
Volkan Yazici commented on LOG4J2-3614:
---------------------------------------
This has turned out to be a bug in {{InstantFormatter}} used by
{{JsonTemplateLayout}}. As a matter of fact, neither {{PatternLayout}} supports
your date format. That is, the following configuration
{code:xml}
<PatternLayout pattern="%d{HH:mm:ss.nnnnnnnnn}"/>
{code}
will still log in {{yyyy-MM-dd HH:mm:ss,SSS}} pattern.
Due to historical reasons, Log4j has two internal date-time formatter
implementations: {{FixedDateFormat}} and {{FastDateFormat}} – I guess, either
only the latter or both were borrowed from Apache Commons long time ago.
{{FixedDateFormat}} is faster than {{FastDateFormat}} with the cost of
supporting less pattern combinations. {{PatternLayout}} _only_ uses these two
date-time formatters. Since {*}your pattern is supported by neither{*},
{{PatternLayout}} catches the exception (thrown by {{FastDateFormat}}) and
falls back to {{FixedDateFormat.FixedFormat.DEFAULT}}, which is {{yyyy-MM-dd
HH:mm:ss,SSS}} I have shared above.
JSON Template Layout uses {{InstantFormatter}}, which is a single entry point
for the all following 3 formatters _in the given order_ (due to performance
reasons): Log4j {{FixedDateFormat}}, Log4j {{FastDateFormat}}, and Java
{{DateTimeFormatter}}. As discovered in LOG4J2-3075, {{FixedDateFormat}} and
{{FastDateFormat}} don't support all date-time patterns, hence the Java
{{DateTimeFormatter}} fallback. Though {{InstantFormatter}} fails to catch the
exception thrown by {{FastDateFormat}} and simply the entire layout
configuration fails. In df45a4611099860254c68540480fc40ea0a89ac4, I have
hardened the {{InstantFormatter}} against {{FixedDateFormat}} and
{{FastDateFormat}} failures. Your {{HH:mm:ss.nnnnnnnnn}} pattern should work
and produce identical output to {{HH:mm:ss.SSSSSSSSS}}.
I am reluctant to update the docs to include example patterns containing
nanoseconds. For one, nanosecond precision is not supported by Log4j out of the
box, you need some configuration to do. Second, it simply works as one would
expect from Java {{DateTimeFormatter}}.
I will mark the story as resolved. Would you verify the fix using
{{2.19.0-SNAPSHOT}} version (which should be available in ~1h as soon as [this
CI job|https://github.com/apache/logging-log4j2/actions/runs/3218171914]
completes) and close the story, unless you have objections, please?
> Update documentation after LOG4J2-3075
> --------------------------------------
>
> Key: LOG4J2-3614
> URL: https://issues.apache.org/jira/browse/LOG4J2-3614
> Project: Log4j 2
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 2.17.2
> Reporter: Strainu
> Assignee: Volkan Yazici
> Priority: Minor
>
> After LOG4J2-3075 was implemented, the JsonTemplateLayout timestamp resolver
> documentation should be updated to reflect the new feature.
> It's especially important to do so since the second fragment identifier used
> here ('S') is different from the one described in, e.g.
> [https://logging.apache.org/log4j/2.x/manual/layouts.html] (which is 'n'). I
> don't have enough experience with Log4j to determine if this inconsistency is
> a bug or not, but an entry in the JsonTemplateLayout documentation would
> help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
