I agree that writing the expression language using a lexer & parser is good.
I've been working toward this goal and I was planning on using JFlex and byacc/J. Which lexer & parser does LBEL use? The conversion to postfix doesn't prevent short-circuiting during evaluation (supported by AndRule, OrRule). The point of my previous email is two parts: - I'd like to see LBEL implement actions by relying on rules in o.a.l.rule. - Where it makes sense (personal preference only), I'd like us to to keep as much of the existing operator and keywords as possible when issues like inconsistency and verbosity don't rule them out. A few language-questions: - Are parens supported? - How are properties supported? prop.xxx, prop(x), or something else? - How is legitimate white space supported? (single ticks, quotes?) - Spaces could show up in a property key...is that supported? I'm looking forward to seeing the results. Scott -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thu 1/27/2005 5:36 AM To: Log4J Developers List Cc: Subject: RE: [NEW] Log4j Boolean Expression Language (LBEL) At 09:59 PM 1/26/2005, you wrote: >Technically, this would be a second implementation of a boolean expression >language for logging events, after ExpressionRule. ;> LBEL is an language in the sense that it is defined by a formal grammar. However, if one considers the possible set of texts that are acceptable, then ExpressionRule and LBEL are quite similar as you point out. >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? A design where the parser is separate from the lexer allows for much more variation in the language. For example, it becomes very easy to add new keywords supporting LoggingEvent fields. Just as importantly, the syntax tree returned by the parser can be used to short-circuit unneeded branches something which is strictly impossible to do when syntax tree is in postfix form. LBEL builds upon your work. I expect that once you see the results you will soften your stand. >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 Postfix form avoids recursion when evaluating the expression. However, when the tree is in postfix form every element must be evaluated and short-circuiting dead branches in AND/OR expressions is not possible. >- 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. As mentioned above, LBEL builds upon your work. -- 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]
