logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: svn commit: r948664 - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core: ./ appender/ filter/
Date Thu, 27 May 2010 10:55:03 GMT

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.


To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message