[logback-dev] TurboFilters to transform events

[Ceki Gülcü]

Attaching filters to loggers is not so easy because it would require a
logic for filter chaining. I think user would have difficulty
understanding that logic. Moreover, filter chaining would involve
walking up logger the hierarchy which would be much slower than what
we have currently.

BTW, have you developed your own custom turbo filters?


On 18/03/2010 2:17 PM, Ralph Goers wrote:
> I think you should leave TurboFilters the way they are. However, you could allow filters to be attached to Loggers. Then the user could transform the event there.
>
> Ralph
>
> On Mar 18, 2010, at 3:56 AM, Ceki Gülcü wrote:
>
>> Hello all,
>>
>> At present time, a TurboFilter cannot modify the contents of an
>> event. This decision was made in order to avoid the cost of
>> constructing a LoggingEvent (about 20 nanoseconds) which would be
>> later tossed out by the logger-level filter. 20 ns is not much but in
>> absolute terms but considering that invoking the logger-level filter
>> costs 3ns, 20ns is quite a steep price to pay in relative terms on
>> every logger printing method invocation (for disabled logger
>> requests).
>>
>> For the case where there are no turbo filters installed, performance
>> would remain quasi-identical. For the case with one or more turbo
>> filters installed, there would be an extra cost of 20ns. However,
>> since invoking even the most rudimentary turbo filter costs 40ns or
>> more, I think the 20ns overhead is well spent considering that it
>> would allow turbo filters to transform events.
>>
>> Unfortunately, the TurboFilter interface would need to be modified
>> breaking compatibility with existing turbo filters.
>>
>> Comments?
>>
>> --
>> Ceki