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 know you mentioned getting git set up. One thing that would help here is instead of simply adding comments (which I don't mind), for you to fork the code and make some of the changes you are suggesting or simply have ideas about. Trying out your own ideas might a) either clear up your questions, b) provide an alternative that is better or c) just give us two options instead of one. Ideally, you and I shouldn't be the only two involved in this. Anyone else participating on this list should definitely join in. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
