In my configuration I have
<properties>
<property name="log_env">${sys:environment:-lab}</property>
<property name="flow_lab">${sys:flow_match:-ACCEPT}</property>
<property name="flow_prod">NEUTRAL</property>
<property name="level_lab">INFO</property>
<property name="level_prod">INFO</property>
</properties>
<MarkerFilter marker="FLOW" onMatch="${flow_${log_env}}" onMismatch="NEUTRAL”/>
This will set the onMatch value to the value of the flow_match system property
in the lab or
ACCEPT if it isn’t set and to NEUTRAL in production. However, with 2.14.1 this
became
unnecessary as one can now do:
<SystemPropertyArbiter propertyName="env" propertyValue=“lab"”>
<MarkerFilter marker="FLOW" onMatch=“ACCEPT" onMismatch="NEUTRAL”/>
</SystemPropertyArbiter>
This would only add the filter to the configuration in the “lab” environment,
which is even
better than having a filter defined with both onMatch and onMismatch as NEUTRAL.
Ralph
> On Dec 19, 2021, at 3:19 AM, Stig Rohde Døssing <[email protected]>
> wrote:
>
> Hi,
>
> The fix for https://issues.apache.org/jira/browse/LOG4J2-3230 looks like it
> disables recursive interpolation for strings that are not sourced from the
> log4j configuration. I'm wondering why recursive interpolation is desirable
> at all, at least as a default? Is it so you can have your config do
> something like $${env:VARNAME} and let the operator specify a pattern in
> VARNAME?
>
> Assuming recursive interpolation is useful at all, is deeply nested
> recursive interpolation useful? Could it make sense to limit recursion to a
> few levels (e.g. 3 or 5) by default, and let users raise that limit via
> system property if they really need it? I can't think of a case where you
> would want deep nesting, but maybe there's a use case?
>
> Sorry if this is well-trodden ground, I'm just having a hard time
> understanding why this feature exists in its current form.
