On Thu, Oct 10, 2024 at 4:09 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
> Hi Gary, > > On Wed, 9 Oct 2024 at 16:34, Gary D. Gregory <ggreg...@apache.org> wrote: > > My proposal is to allow a user to _not_ define any custom filters by > reusing a new Result enum value called “Throw”. When a filter returns > “Throw”, then Log4j throws a new LoggingException subclass called > FilterLoggingException. > > I find Log4j's 3-valued filtering system already very complex: > > - it is difficult or impossible to make a composite filter for a > moderately complex boolean expression. If you have 3 filters that > check A, B and C, how do you make a filter for `(A OR B) AND C ? > ACCEPT : NEUTRAL`? > I agree that the Filtering system should be different (maybe a predicate tree instead of an array to allow for boolean logic), but these types of changes are way beyond anything I am describing. I am proposing a new feature that fits into the existing system and that would prevent users from writing custom code that is beyond what a casual developer would be comfortable doing (IMO). Gary > - the difference between `ACCEPT` and `NEUTRAL` is never used, except > for global filters[1]. > - writing global filters requires a lot of knowledge about Log4j. For > example the `Throwable` associated with a log event, can be hidden in > one of 3 parameters (see the second `local/script.groovy` example in > the documentation[2]. > > Given that I am not eager to complexify filters with yet another possible > result > > Piotr > > PS: Note, Logback solves the boolean expression in a simple way: it > has an `EvaluatorFilter` that uses a tree of `Predicate<LogEvent>` > components to decide, which result to output. > > [1] https://logging.apache.org/log4j/2.x/manual/filters.html#logger-stage > [2] https://logging.apache.org/log4j/2.x/manual/filters.html#Script >
