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
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
> On Apr 3, 2022, at 11:59 AM, Piotr P. Karwasz
> wrote:.
>
> I would go even further, regarding the properties format: no Log4j2
> developer uses it and that explains why there are still many bugs in
> the `PropertiesConfiguration`.
Bugs?
When it was first implemented it followed a
Hi Ralph,
On Sun, 3 Apr 2022 at 19:00, Ralph Goers wrote:
> The enhancement you suggest would make the properties configuration different
> than
> the other configuration formats as they all require the Filters element. This
> is yet another
> example of why most (or all) of the log4j 2
I would expect the Properties issue would affect all the implementations.
The enhancement you suggest would make the properties configuration different
than
the other configuration formats as they all require the Filters element. This
is yet another
example of why most (or all) of the log4j 2
Hello Stamatis,
I posted a working solution on SO:
logger.t1.filter.M.type = Filters
logger.t1.filter.M.f1.type = RegexFilter
logger.t1.filter.M.f1.regex = .*SQL.*
logger.t1.filter.M.f1.onMatch = NEUTRAL
logger.t1.filter.M.f1.onMismatch = DENY
logger.t1.filter.M.f2.type = RegexFilter
