[
https://issues.apache.org/jira/browse/LOG4J2-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
K P updated LOG4J2-3480:
------------------------
Description:
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...
was:
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...
> 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 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)
