[logback-user] TurboFilter scope
listid at qos.ch
Tue May 20 10:58:47 CEST 2008
Don Griffin wrote:
> On the hierarchy walking part, you are correct about costs. Of course,
> one could flatten and cache the result. Since changes in Logger
> behavior on-the-fly are rare (in comparison to log statements), one
> could store the flattened TurboFilter on a Logger and invalidate it
> (set to null) for all children in the event of a change on a
> parent. For simplicity, this could be done with an AtomicReference to
> avoid undesirable lock hierarchies.
I am not familiar with AtomicReferences. They sound like "fun".
> Of course, using AtomicReference and TurboFilter (as opposed to a
> Collection), the hierarchy walking may not be too terrible. Oh well, I
> am sure you know what they say about premature optimization.
Yes, premature optimization is the root of all long discussions.
> Just thoughts from one who is completely unfamiliar/ignorant of how
> the internals work. I'm sure you'll have much better insight on how
> such a feature might be implemented.
Well, maybe, but your analysis above was pretty good.
> In my particular use case, I'm working in a server environment. We
> have several objects that we would like to use to adjust the logging
> in a TurboFilter kind of way (as opposed to an Appender). Say, per
> user or per group or maybe by some other property of our application
Ignoring performance considerations, i.e root of all long
discussions, if you wish to filter per user or per group, does it also
make sense to add per logger filtering on top of filters based on the
user? Does your use case call for "user+logger"-based filters or just
If your use case calls for user-based filters, then is it accurate to
say that your request for "user+logger"-filters is essentially
motivated by improving filtering performance?
> We think we can force-fit the data we need in to the MDC. Someday I'll
> post a question/suggestion related to MDC, but for the sake of this
> thread, I'll save that one for another time. :)
As you wish.
> Again, thanks!
More information about the Logback-user