[
https://issues.apache.org/jira/browse/LOG4J2-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524366#comment-17524366
]
K P commented on LOG4J2-3480:
-----------------------------
I understand all this interpolation is a complex matter (and the log4j2
security issues at the end of 2021 didn't make it any easier, I guess.)
I played around a bit with <Properties>:
{noformat}
<Properties>
<Property name="headerProp">${foo:header}</Property>
</Properties>
<PatternLayout>
<Pattern>....</Pattern>
<Header>${headerProp}</Header>
</PatternLayout>{noformat}
(PS: seems I needed a different property name (not just "header"), otherwise it
somehow got confused with our lookup and get into some infinite recursion or
so?)
But that doesn't make any difference.
I've read through the document you referred to about the 2.17.0 interpolation
changes.
Surprisingly our setup and configuration was actually _not yet_ affected by
those 2.17.0 changes.
In fact, it seems to behave as it has for many years up until 2.17.1. That's
why the breaking behavior in 2.17.2 (which I'd suppose to be just a minor
log4j2 update) was rather unexpected.
Also it's remarkable that as of 2.17.2 the $$ interpolation still works as
before when we're using the _programmatically built_ configuration (where we
still set the same header string containing the double $$ lookups).
Anyway, for our specific use, we have some workarounds:
* stick to log4j 2.17.1 for a while, to be sure
* move to log4j 2.17.2, but then in our custom lookup, for ${foo:header}, just
let the lookup return the header string where double $$ are replaced by single
$ ( {{return header.replace("$$", "$");}} ), which for our log4j2.xml-based
config seems to do fine, as the single $ now seem to be lazily evaluated as of
log4j 2.17.2 ( ? ).
But when we use programmatically built configuration, we somehow still need to
set the header string unaltered, i.e. containing the double $$, to get the lazy
evaluations. ( {{.addAttribute("header", header)}} )
For our use cases, that seems to be sufficient. However, I cannot judge whether
other users might be hit with this - or some variations on this - when they
need lazy evaluation, or the opposite, non-lazy evaluations. Also because this
changed in the minor update (not in 2.17.0), and because I notice some
difference now between programmatic configuration and log4j2.xml-file-base
configuration, I can't judge if these changes were fully intentional in this
particular update, or partly by accident, and if we'd risk another
(unintentional?) change in behavior in subsequent (minor) updates.
> 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
> Priority: Major
> Labels: interpolation, lookup, regression
>
> 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 _no_ 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.7#820007)
