[
https://issues.apache.org/jira/browse/LOG4J2-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478632#comment-17478632
]
Volkan Yazici commented on LOG4J2-3343:
---------------------------------------
There are many features we can support in the filtering aspect of this API,
though all these features can perfectly be implemented by regex. Put another
way, we will simply be introducing a DSL layer atop regex. Regex is already a
widely-known well-established DSL, I don't think we need a wrapper around it.
Regex is indeed not the most developer-friendly pattern matching DSL, though it
is the de facto standard surrounded by a battle-tested tooling and ecosystem.
Additionally, JTL templates will most likely be touched rarely. I don't see the
complexity level of regex as a blocker here. Not to mention a very long regex
most of the time hints wrong design decisions and the fix is somewhere else.
Also note that {{excludePatterns}} will be duplicating the functionality of
{{pattern}} in a different way, hence, the execution order needs to be
documented too for conflicting cases.
I don't want to act like the police officer for JTL. Log4j is a community
project and I am thankful for accepting me and JTL as a part of it. That said,
I am over-sensitive about JTL, which is the 4th iteration of
{{log4j2-logstash-layout}} and this time I want to get it right. Every single
keyword in JTL source & API is subject to a consistent and conservative
convention. For instance, did you notice every variable and template keyword is
a noun, there are no verbs? Likewise, every method is a verb. There are no
features with intersecting functionality. In particular, while designing _map
resolver_ API, I put quite some thought into it. Back then I considered
{{includes}} and {{excludes}} arrays containing regex'es, similar to Maven
plugin conventions. Yet settled down to simple {{{}pattern{}}}, which can
encapsulate all functional scenarios, is intuitive, simple to implement, and
beautifully enables {{{}replacement{}}}. Hence, yes, I am strongly opinionated
and I am against any matching functionality besides {{pattern}} in this case.
API bloat is too easy to contribute to and nearly impossible to remediate once
it's in.
> Add ability to use exclusion pattern filter on Map Resolver keys
> ----------------------------------------------------------------
>
> Key: LOG4J2-3343
> URL: https://issues.apache.org/jira/browse/LOG4J2-3343
> Project: Log4j 2
> Issue Type: New Feature
> Components: JsonTemplateLayout
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Priority: Major
> Fix For: 2.17.2
>
>
> Map Resolver currently supports specifying a pattern to filter for allowed
> keys in the map being resolved. I'd like a complementary feature to specify a
> pattern to filter for excluded keys from the map being resolved. It may also
> be beneficial to provide a similar option for excluded keys as full string
> matches rather than always using a pattern.
> For an example use case, suppose I copy request HTTP header names and values
> into the ThreadContext for every request. In Spinnaker microservices, this
> includes custom headers like {{X-Spinnaker-Groups}} which contains a list of
> groups the authenticated user belongs to which are filled in by the Fiat
> microservice (used for integrating authentication and authorization with
> various providers and providing a facade over Spring Security). If I want to
> exclude this header from being logged, I can currently set a negative
> lookahead pattern like {{(?i(?!x-spinnaker-groups))}} which works effectively
> the same, but how many developers like reading regex incantations like these?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
