On Sun, 3 Apr 2022 at 21:53, Ralph Goers <ralph.go...@dslextreme.com> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
