At 08:02 AM 1/8/2005, you wrote:
I thought I'd throw this filter out there for discussion. Joran implicit
actions are really powerful once you figure out how to use them.
This filter should support composability and negation, but it's pretty
complicated compared to the expressionFilter alternative.
The only real benefit to using this filter over defining an AND-based
expression and using expressionFilter is for those folks who have written
custom filters that trigger based on internal state or some non-logging
event stimulus.
The other reason to use this filter over an AND-based expression filter is
if the expression rule evaluation is dog slow and the filter evaluation
was fast (hopefully this is no longer the case).
It may not be what others were interested in, but it seems to work well
and doesn't require any framework changes.
I won't be offended if it's replaced/reverted, but I thought I'd start the
ball rolling.
Nesting filters implies logic trees which is a different approach than
filter chains. Up until now, I was against mixing the two approaches
because of the need to avoid maintaining two competing approaches of
the same. If you the same things is implemented in two different ways,
then the maintenance costs increase linearly, while user support costs
increase exponentially. (In general, if users can express some logic
in two radically different ways, then the number of confused users
increases dramatically.)
However, in this particular, I think the additional power offered by
nested filters will allow the user to express her logic more
naturally. The AndFilter is a point in case. Thus, please kindly
ignore my previous comments about reverting AndFilter.
BTW, thank you Scott.
Scott
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
