Technically, this would be a second implementation of a boolean expression language for logging events, after ExpressionRule. ;>
Other than using a real parser (which I agree is a good idea, particularly if sister projects would be interested in implementing the same support), why do we need a different language than what we have now? Background on existing expression rule: The existing expression language is self-contained within a few classes: - o.a.l.rule.InFixToPostFix class, converts infix expressions to postfix - o.a.l.rule.ExpressionRule - static inner class PostfixExpressionCompiler converts a postfix expression as text into a rule (relying on rulefactory and a context stack). - o.a.l.rule.RuleFactory, calls static getRule methods on the individual rules, which take the context stack as a parameter and returns a rule). As events are evaluated, rules retrieve values associated with keywords in the current event using o.a.l.spi.LoggingEventFieldResolver The value returned by the resolver is used in the evaluation. For example, if the expression was Level > INFO, for an event with a level WARN, a LevelInequalityRule would get the WARN level using LoggingEventFieldResolver and the rule would perform the evaluation, returning true or false. -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wed 1/26/2005 12:06 PM To: [email protected] Cc: Subject: [NEW] Log4j Boolean Expression Language (LBEL) Hello all, Having just finished testing the first implementation of a boolean expression language for logging events, I'd like to explain its salient features. LBEL allows the user to write arbitrarily complex boolean expressions relative to logging events. For example, (level >= INFO AND method = 'foo') OR (logger CHILDOF 'some.package') In other words, LBEL is a classical boolean expression language where OR, AND, NOT and parentheses carry their usual precedence and meaning. However, LBEL supports several sub-expressions and keywords specific to the evaluation of logging events. The implementation is designed to short-circuit the evaluation of the right side of 'AND' and 'OR' expressions resulting in tremendous performance gains in some cases. For example, if 'left-side' is true, LBEL will skip the evaluation of the right side in the following expression. (left-side) OR (right-side). Similarly, if left-side is false, the right-side will not be evaluated for AND expressions. More formally, here is the grammar for LBEL <bexp> ::= <bexp> 'OR' <bterm> <bexp> ::= <bterm> <bterm> ::= <bterm> 'AND' <bfactor> <bterm> ::= <bfactor> <bfactor> ::= NOT <bfactor> <bfactor> ::= '(' <bexp> ')' <bfactor> ::= 'level' <numerical_op> 'DEBUG'|'INFO'|'WARN'|'ERROR' <bfactor> ::= 'message' <string_op> <litteral> <bfactor> ::= 'logger' <string_op> <litteral> <bfactor> ::= 'logger' 'CHILDOF' <litteral> <bfactor> ::= 'timestamp' <numerical_op> <NUMBER> <bfactor> ::= many other sub-expression could be easily added <numerical_op> ::= '=' | '!=' | '>' | '>=' | '<' | '<=' <string_op> ::= '=' | '!=' | '>' | '>=' | '<' | '<=' | '~' | '!~' '~' and '!~' designate regular expression macthing. The usual grammar transformation techniques have been applied to put the above grammar in LL(1) form so that it could be parsed top-down. Most of the difficult parts of the implementation are done and tested. If there are no objections, I will commit them shortly. -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
