Re: Configure composite filter for specific logger in Log4j2 via properties file

On Sun, 3 Apr 2022 at 21:53, Ralph Goers <[email protected]> wrote:
> Bugs?
>
> When it was first implemented it followed a standard format (which should
> still work). Almost immediately folks started “simplifying” it since the standard
> format is cumbersome. But being cumbersome is not a bug.
>
> The biggest issue is that we simply don’t document it very well and don’t
> have a lot of examples.
>
> But I wouldn’t call having to declare the Filters element a bug.

If not bugs, then discrepancies between the XML format and the
properties format. One might expect the dot-separated fragments of a
property to correspond to the element hierarchy in XML. For example:

appender.$1.layout.pattern

might correspond to a
`/Configuration/Appenders/Console/PatternLayout/@pattern` XPath.
Discrepancies start to appear in the `<Properties>` and `<Loggers>`
sub-trees. The former has rules of its own, while the latter:
1. does not allow an equivalent of `<Loggers><Root ...` (I would
expect `logger.$1.type = Root`),
2. does not allow a strict equivalent of `<Loggers><Logger
...><AppenderRef>` (I would expect `logger.$1.$2.type = AppenderRef`,
while it is `logger.$1.appenderRef.$2`),

While `logger.$1.filter` follows the same rule as
`logger.$1.appenderRef` (i.e. introduces a "virtual" XML element for
the filters), there is a difference between the two: there can be only
one filter in a `<Logger>` element. That is why it seems natural for
me to interpret `logger.$1.filter` as the equivalent of
`<Loggers><Logger ...><Filters>`.

Piotr