On May 26, 2010, at 11:01 PM, Ralph Goers wrote: > I'm not sure what the appropriate way to respond to all the comments is going > to be. Some of them I agree with and will make changes when I get the chance. > Many of them just need an explanation or I disagree with the comment - not > sure what to do about those. For example, in Logger - > > @doubt All the isEnabled methods could be pushed into a filter interface. > Not sure of the utility of having isEnabled > * be able to examine the message pattern and parameters. > > 1. The Filter interface doesn't return a boolean but ACCEPT, DENY or NEUTRAL > where isEnabled is true or false. Filters operate in a chained fashion until > either ACCEPT or DENY is returned, so adding isEnabled to that interface > doesn't make sense. > 2. The value of having the the message and parameters is for performance. > Creating the LogEvent isn't cheap. So it is essential to have global filters > operate on the parameters directly. Of course, all the variations could be > paired down but that would require user's to enter a null parameter where it > isn't needed. I prefer to make the interface easier for the user, not the > implementor. > > How should I add this to the @doubt? >
I'm playing by ear, but if there was @doubt that warranted a discussion, then I'd file a JIRA issue, replace the @doubt with a @issue with the JIRA issue and move the discussion to the JIRA issue. "a filter interface" didn't specifically mean the current Filter, just a whole lot of methods on Logger are related to deciding whether a whether a logging request would be processed and those conceptually could be isolated into one interface. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
