[jira] [Commented] (LOG4J2-3480) Changed behaviour (regression) in 2.17.2 lookup plugin or string interpolation

["K P (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574315#comment-17574315 ] 

K P commented on LOG4J2-3480:
-----------------------------

It took a while to find some time again for this issue, so with some delay, my further feedback:

 

The new {{evaluate()}} interface methods indeed seem the way the go:

I've adapted our custom Lookup plugin to override
{{{}LookupResult evaluate(LogEvent event, String key{}}})
as well (super class AbstractLookup takes care of the other evaluate() method overload) ,

and let it return a simple custom LookupResult, that contains the String value (from before), but now also has the "isLookupEvaluationAllowedInValue" flag {_}true{_}.
(this simple custom LookupResult is actually similar to the private ConfigurationPropertyResult contained within log4j2's PropertiesLookup).

 

Still need some more testing etc to be sure, 
but it now looks that we again get the behavior we had until log4j 2.17.1, dealing correctly with the double $${...} in the header lookup string.
And again behaving consistently between the log4j2.xml-based log configuration vs the programmatic log configuration.

 

 

> 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.10#820010)