I've raised a PR at https://github.com/apache/logging-log4j2/pull/644, let me know what you think.
Den søn. 19. dec. 2021 kl. 17.19 skrev Ralph Goers < [email protected]>: > 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. > >> > >> > >
