Thanks a lot for the feedback everyone! I also find the property syntax a bit hard to use compared to the other available options. I rarely use properties when I am starting a new project but in projects that it is used already I don't have many options apart from learning it and improving it if necessary. Migrating from property syntax to another is always an option but this can have quite a big impact on various aspects so I wouldn't push hard into this direction.
Few comments on the main points raised so far: 1. Wrap individual filters in a "Filters" component I think it makes sense since that would make it inline with how the XML syntax works and it would solve the problem of multiple filters defined together. Alternatively, raising an error or warning when a filter is defined without an explicit "filters" step would be more helpful for end-users to understand they are doing something wrong. I have a few concerns around this but I guess they could be discussed under the JIRA case if we decide to move this forward. 2. Deterministic order on composite filters It could be a nice feature since users could order their filters and possibly have performance gains as well. I am not sure though if it is a good idea to make this dependent on the order the properties/elements are defined in the configuration. Looking back into this it was a bad idea from my side to rely on the order that filters are defined. Order of properties, or elements in XML, JSON, etc., shouldn't matter in general so people (including myself) shouldn't rely on it. If we really want to enforce an order on the evaluation of filters then maybe it makes sense to introduce a dedicated attribute. 3. Documentation for property syntax & composite filters I agree with others, it would be very helpful if they were some more examples in the documentation and/or code base. The third point can be adressed rather easily since with Piotr's help there is a working example so I can raise a PR for adding the unit test and/or a respective example somewhere in the docs. If there is consensus about points 1, 2, I can create the respective JIRAs and start working on them when I find some time. Best, Stamatis On 2022/04/03 21:51:31 "Piotr P. Karwasz" wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
