[logback-user] TurboFilter scope

Ceki Gulcu ceki at qos.ch
Mon May 26 13:14:42 CEST 2008


Hello Don,

Thank you for the compliment abut logback.

Your proposal is quite interesting and has pros as well as cons.

On the pros side, it would indeed eliminate the need for evaluating
TurboFilters for loggers which do not inherit any. Also, as you have
stated, inherited filters allow for finer grained control. However,
such flexibility comes at a cost. On the cons side, each logger would
need to walk the hierarchy for determine the filters that would
apply. Walking this hierarchy in a multi-threaded environment does not
come totally free.

Thus, I would like to ask you whether you could describe your use-case
in more detail. Could you describe your use-case please?


Don Griffin wrote:
> Firstly, as this is my first post, thanks for an overall great library!
> 
> Having just read the section on TurboFilters, they are (almost) just 
> what I need. I fear that the way they are implemented puts undue penalty 
> and difficulty on their performance.
> 
> I did scan the past several months in the archive and did not find any 
> mention of TurboFilter, even still, this may be something someone else 
> has already suggested. If so, I apologize for the noise. In any case, 
> here is my suggestion:
> 
> Why not put TurboFilters on Loggers instead of the global context? That 
> is, the example from the (very helpful and well done) manual:
> 
>   <configuration>
>     <turboFilter class="chapter6.SampleTurboFilter">
>       <Marker>sample</Marker>
>     </turboFilter>
> 
>     <appender name="STDOUT" class="...">
>       ... snip ...
>     </appender>
> 
>     <root>
>       <appender-ref ref="STDOUT" />
>     </root>
>   </configuration>
> 
> Would change to:
> 
>   <configuration>
>     <appender name="STDOUT" class="...">
>       ... snip ...
>     </appender>
> 
>     <root>
>       <turboFilter class="chapter6.SampleTurboFilter">
>         <Marker>sample</Marker>
>       </turboFilter>
>       <appender-ref ref="STDOUT" />
>     </root>
>   </configuration>
> 
> Almost the same, and it would achieve the same result as the original. 
> In my case, however, I could apply a TurboFilter to only the loggers 
> that need it:
> 
>   <configuration>
>     <appender name="STDOUT" class="...">
>       ... snip ...
>     </appender>
> 
>     <root>
>       <appender-ref ref="STDOUT" />
>     </root>
> 
>     <logger name="foo">
>       <turboFilter class="chapter6.SampleTurboFilter">
>         <Marker>sample</Marker>
>       </turboFilter>
>     </logger>
> 
>     <logger name="foo.bar">
>     </logger>
>   </configuration>
> 
> In this case, the "foo.bar" logger would inherit the TurboFilter from 
> the "foo" logger. In essence, each Logger object would have its own 
> collection of TurboFilter objects that are the concatenation of any 
> filters configured on itself, followed by its parent, grand-parent, etc. 
> on up to the root of hierarchy.
> 
> This approach should greatly reduce the total penalty for using such a 
> powerful mechanism and at the same time give finer grained control over 
> which filters apply to which loggers.
> 
> Any thoughts?
> 
> Best regards,
> Don
> 
> 



More information about the Logback-user mailing list