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.


On 2022/04/03 21:51:31 "Piotr P. Karwasz" wrote:
> On Sun, 3 Apr 2022 at 21:53, Ralph Goers <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to