At 10:07 29.05.2002 -0700, Mark Womack wrote: >Ceki, > >So, I think we are on the same page here. The RejectOnMismatch property is >one way to solve it, and it might be a better way. I don't know. I was >going to propose this: > >1) Leave the current set of varia filters as they are and possibly deprecate >them in a future version. Create a o.a.log4j.filters package and create a >new set of base filters that are more powerful and flexible (this does not >mean changing the current, underlying filter design...only exposing the >existing ternary logic in way that is useful). The current set of varia >filter functionality would migrate to the new package, etc. We could work >out the new design.
Adding new filters to o.a.log4j.filters sounds good. >2) Leave the current set of varia filters as they are and simply extend >their interface to expose more of the filter features. I was going to >recommend 2 new methods setMatchReturnVal(Level) and >setMismatchReturnVal(Level). The current filters could default to their >current match/mismatch values for each return value, AcceptOnMatch would set >these 2 values so the filters act like they do today, ensuring backward >compatibility. But these 2 new properties could be set via configuration >files and expose the useful functionality. Or we could look at adding >Mismatch filters with RejectOnMismatch() instead. Whichever works better. You mean setMatchReturnVal(String val) where val is one of "ACCEPT", "DENY" or "NEUTRAL". Same for setMismatchVal(). Correct? >Or there might be a third option I have not thought of yet. I don't have a >strong opinion of one over the other, as long as the useful functionality is >exposed via a larger set of available filters. That is the goal. 1) is good. >-Mark -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
