This is a timely message, I've already written the lexer for the keywords/operators supported by ExpressionRule and I was about to write the parser.
This is very similar to ExpressionRule and its reliance on all of the rules in the o.a.l.rule package (of course). I was going to do something very similar, and delegate the parser actions to the rules in the rule package. Similarities to current expressionRule: Some syntactic minor differences AND/OR instead of &&/||, ~ instead of LIKE for regular expressions. AndRule already doesn't evaluate the right hand side of the rule. What is !~? childOf operator is similar but not identical to to partial-text match operator, but easy to add as a rule. The classes in o.a.l.rule are useful in this context, in that they can be built programmatically instead of requiring the creation of an expression (not always needed, but useful). Would you reuse the rule package (delgate its actions to the rules in o.a.l.rule)? I'd suggest that. I'd also like to hear people's opinions on what is used to identify the non-relational operators as well as the keywords. Examples of options for keywords and operators MSG or MESSAGE or ? LIKE or ~ or ? ! or NOT or ? && or AND or ? || or OR or ? PROP.X OR PROP(X) or ? etc. Of course, there are others. I personally like the keywords already used by ExpressionRule because I'm used to them, but if others feel strongly I'd get used to it. Scott -----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]
