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