Hi Mark, I understand better now. The advantage of SetLocationInfoFilter is that it allows you to set the location info on some events but not on others. The penny drops making a clinking sound.
Reading the code for GenericMatchFilter my impression was that is factored out the acceptance/denial logic in StringMatchFilter. I am trying to judge if after factoring, the logic is simpler or on the contrary more complicated. I tend to think that it makes the logic simpler but am unsure. As for the typo in your name, I apologize. I usually double check the was I spell names but somehow did not catch that M != W. Sorry. At 09:39 29.03.2002 -0800, you wrote: >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 -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
