RE: SetLocationInfoFilter, was: [SUBMIT] GenericMatchFilter.java; SetLocationInfoFilter.java

[Mark Womack <mw...@bevocal.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: SetLocationInfoFilter, was: [SUBMIT] GenericMatchFilter.java; SetLocationInfoFilter.java

[Ceki Gülcü <ce...@qos.ch>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>