K P created LOG4J2-3480:
---------------------------
Summary: Changed behaviour (regression) in 2.17.2 lookup plugin or
string interpolation
Key: LOG4J2-3480
URL: https://issues.apache.org/jira/browse/LOG4J2-3480
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.17.2
Reporter: K P
Something (breaking) changed in the way lookups and/or string interpolation is
done, between versions 2.17.1 and {*}2.17.2{*}.
Our situation has some complexities (for historical reason):
* we can use {_}either a configuration via log4j2.xml file{_},
or either the same _config built programmatically_
* we have a {_}custom lookup plugin{_}. Let's call it "foo" for the purpose of
illustration:
{{@Plugin(name = "foo", category = "Lookup")}}
The lookup has a few keys.
* e.g.: _${foo:version}_ , _${foo:options}_ , etc.
(reason or underlying implementation doesn't matter here - something to do with
context based on dynamic modules, threadgroups, etc)
* The lookup also has the keys _${foo:header}_ and _${foo:footer}_ , which
contains a larger snippet, INCLUDING some of its other keys.
e.g. (simplified adapted example)
"{{{}Here some header text for version {*}$${*}{foo:version} at {*}$${*}{date}
etc etc{}}}"
These double $$ are important here , see further below.
Then we have in our <PatternLayout> configuration the following:
{{ <PatternLayout>}}
{{ <Pattern>... omitted here ...</Pattern<}}
{{ <Header>${foo:header}</Header>}}
{{ <Footer>${foo:footer}</Footer>}}
As a result, each logfile is started with the well-defined header snippet (this
string hard-coded inside the lookup plugin), but that header has some variable
content (${foo:version}, ${foo:options}, ${date} ), which is substituted in
turn. And each logfile is terminated by the foo:footer. Having this header and
footer defined by the lookup ensures that the end-user easily configures them
in the fixed header and footer in his log4j2.xml.
Now in our application we also allow a +programmatically built log+
configuration:
{{ builder.newLayout("PatternLayout")}}
{{ .addAttribute("header", HEADER)}}
{{ .addAttribute("header", FOOTER)}}
whereby HEADER and FOOTER are the same strings as returned by our custom foo
lookup plugin when it returns foo:header and foo:footer. (i.e. containing the
double $$ inside)
+Why the double $$ ?+
We have these since many years: The double $$ ensure that the lookups included
inside the header and footer (e.g. $${foo:version}, but also the $${date} )
+are evaluated at the time that the logfile is actually being written+ !
If instead we used a single $ inside the header and footer, the interpolation
happened only 1x at time of configuration. Which is not what we want.
e.g. when using a single $, then the timestamp in the header was stuck to the
timestamp at the time that our application _loaded the logging config._ Whereas
of course we'd want the timestamp to be current at the time the new logfile was
created.
If I remember well, the same was true for our custom lookup: to ensure it being
{+}re{+}-evaluated at the time the logfile was written, we needed to use a
double $$.
Now this {+}worked fine up until log4j 2.17.1{+}.
+both+ with our _programmatic_ configuration or when configured via _log4j2.xml_
This _still_ works in log4j 2.17{*}.2{*} when we are running with our
*programmatically* built configuration:
However, in log4j 2.17.2 this *no longer* works when the configuration is taken
from the *log4j2.xml* file.
In that case, the expansion of double $${...} no longer works.
Instead, it just prints something like: "{{{}Here some header text for version
${foo:version} at ${date} etc{}}}"
i.e. the double $$ is substituted by a single $ now, but now further
substitution are done. Not at load time, not later at write time.
On the other hand, when in the header string, I now use $ inside $$, then this
now suddenly works in the log4j2.xml-based configuration with substitution at
write-time. Which is clearly a different behavior than up to log4j 2.17.1. And
is also a different behavior than the programmatic configuration.
So there's clearly +something+ has changed unexpectedly in log4j 2.17.2...
I don't know which change or jira issue may have caused it ?
Could it have something to do with, which did some changes in the string
interpolation? LOG4J2-3424 ?
Or can it be related to e.g. LOG4J2-3470 ?
Something else?
I did try using the 2.17.3-SNAPSHOT, but I am still seeing the changed 2.17.2
behavior there...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
