Bug 42099 - ExpressionFilter backport
ExpressionFilter backport
Status: RESOLVED FIXED
Product: Log4j
Classification: Unclassified
Component: Other
1.3alpha
Other other
: P2 enhancement
: ---
Assigned To: log4j-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-04-12 07:04 UTC by Curt Arnold
Modified: 2007-08-15 15:21 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Curt Arnold 2007-04-12 07:04:17 UTC
This enhancement extracts the org.apache.log4j.filter.ExpressionFilter and o.a.l.filter.LocationInfoFilter 
from log4j 1.3 and adapts it to work with log4j 1.2.  The initial goal is to support Chainsaw on log4j 1.2, 
however hopefully the resulting package can be used by log4j 1.2.x users who would like to use the 
ExpressionFilter.
Comment 1 Curt Arnold 2007-04-12 15:30:33 UTC
Should be functional at the writing.  Can be checked out from:

svn co https://svn.apache.org/repos/asf/logging/sandbox/log4j/expression-filter

Maven build will use log4j-1.2.14.jar (which it will download if it hasn't already).  Put a recent Maven 2 on 
path and do:

mvn package : to build jar
mvn site        : to build documentation
mvn install    : to add to local Maven repo   
Comment 2 Curt Arnold 2007-08-15 15:21:05 UTC
Committed changes in rev 566357 that migrates the ExpressionFilter from Jakarta ORO to 
java.util.regex that was introduced in JDK 1.4.  The change should be transparent unless you used 
pattern delimiters in filters like:

MSG LIKE /.*foo/

instead of just writing:

MSG LIKE .*foo

If that level of compatibility is needed, identical bracketing characters could be detected and the rule 
could return true if either the straight pattern or the pattern with bracketing characters removed 
matched the field.  However, since ExpressionFilter was introduced in log4j 1.3, I don't feel the need for 
that level of compatibility unless it that was known to be used in the field.  Feedback appreciated.