Ceki, > Why do you think that calling getLocationInfo multiple times > will cost more > than calling it just once?
I don't (I verified the implementation optimization :-). I'm saying that calling getLocationInformation for EVERY logging event can be very expensive, especially if you only want/need it for events from specific loggers. Configuring a filter chain with subclasses of GenericMatchFilter lets me control the flow of events so that some get the location info set and others do not, thus increasing the overall logging performance for that appender. (When I put SetLocationInfoFilter into the filter chain, I disable the setting of LocationInfo on the appender). I think that this flexibility in controlling the event flow will be useful for other stuff as well. > Not all appenders require the setLocationInfo method and its > implementation > is rather trivial. On the other had, the idea of > SetLocationInfoFilter is very > original. I'll include it in the contribs/MarkMomack/ directory. GenericMatchFilter and SetLocationInfoFilter are all about providing options and flexibility at runtime. Using filters like this allows many different choices to configure the filter chains. And it does not require the developer to write their own filter because the one they have does not have the return value behavior they need to create the filter chain they want. At least that is the hope. A contrib directory is fine, but I think they are generally useful and should be considered for the regular package. But just be sure to name the directory contribs/MarkWomack/ :-) Thanks! -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
