Yes. Even setting it to a ridiculous number like 10 would prevent a lot of problems.
Ralph > On Dec 19, 2021, at 9:17 AM, Stig Rohde Døssing <[email protected]> > wrote: > > Hi Ralph, > > Thank you for elaborating, that makes sense, and I can see how that is > useful. Limiting recursion to some small number of levels, as a default > controlled by system property (or some other mechanism), still seems like > it could be worthwhile, it would close any potential for the issue in 3230 > to crop back up elsewhere. Unless it is common to need tens of levels of > recursion, it might be nice to disallow it by default. > > Den søn. 19. dec. 2021 kl. 17.04 skrev Ralph Goers < > [email protected]>: > >> 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. >> >>
