add keyExcludes to MDC resolvers to prevent overwriting of structural…

[ramanathan1504]

Fixes #4166

Add keyExcludes to MDC resolvers to prevent user-controlled variables from overwriting structural log fields.

[ppkarwasz]

What about requiring loopContext.keyExcludes to be not null, so we don't need a null-check? The performance should be similar.

[ramanathan1504]

are you describing using Collections.emptySet() to avoid the != null check? I can make that change.

[ppkarwasz]

Yes, this should not impact performance and would be easier to understand by developers. You can even add a JSpecify @NonNull annotation on the field, so it is clear it can not be null.

[ramanathan1504]

@ppkarwasz,
fixes 06399c8

[ppkarwasz]

Hi @ramanathan1504,

Looks good to me, with two small comments:

[ppkarwasz]

We probably should compare the performance of two ReadOnlyStringMapResolver instances, instead of comparing Pattern vs Map. This might give us an idea if the changes are worth it.

Map is clearly faster than Pattern, but the relative performance gain can not be determined, since it lacks the time needed to format the map as JSON.

[ramanathan1504]

Benchmark                                       Mode  Cnt  Score   Error   Units
MdcKeyFilterBenchmark.testKeyExcludesResolver  thrpt    5  5.049 ± 0.175  ops/us
MdcKeyFilterBenchmark.testPatternResolver      thrpt    5  1.846 ± 0.023  ops/us

@ppkarwasz 5582862

[ramanathan1504]

@vy done — keyExcludes is gone, it's literal with allowed and disallowed now, and the grammar block in the ReadOnlyStringMapResolver javadoc is updated to match the one u pasted.

Two things your example didn't pin down: disallowed currently wins over allowed, and when pattern is also set a key has to satisfy both — is that what u meant, or should allowed widen the pattern instead?

[ramanathan1504]

@ppkarwasz reworked to the literal grammar @vy proposed on the issue, both your comments are still in — the sets are Collections.emptySet() when absent with @NonNull on the fields, and the benchmark compares two full layouts: 4.562 vs 1.833 ops/us.

A mis-shaped literal now throws the way flatten does, but a typo'd sub-key (disalowed) still parses and silently filters nothing — worth rejecting unknown keys under literal, or leave it as is?