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
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
