On May 26, 2010, at 11:02 PM, Curt Arnold wrote: > > 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.
I'm not sure I like that approach for all of these. That would be a lot of Jira issues for something that is essentially, in a sandbox. There has got to be a better way to have a discussion. I wish I knew what it was. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
