I meant the 'Rule' interface, which now takes a Map which can be used to track matches (it's how I am able to highlight the actual matching text in a partial-text match in Chainsaw).
Rule#evaluate: /** * Returns true if this implementation of the rule accepts the LoggingEvent, * or false if not. * * <p>What True/False means can be client-specific. * * @param e LoggingEvent this instance will evaluate * @param matches a Map of event field keys to Sets of matching strings (may be null) which will be * updated during execution of this method to include field and string matches based on the rule * evaluation results * @return true if this Rule instance accepts the event, otherwise false. */ boolean evaluate(LoggingEvent e, Map matches); Scott On Mon, Feb 6, 2012 at 11:16 AM, ralph.goers @dslextreme.com < [email protected]> wrote: > > > On Mon, Feb 6, 2012 at 11:00 AM, Scott Deboy <[email protected]>wrote: > >> Yeah I don't mind doing that work. One thing that was a slightly >> significant change to the LoggingEvent implementation in log4j 1.2 - I >> needed to be able to track expression matches, which impacted the API a bit >> (find/colorizing expressions are displayed in the gutter on the right, time >> deltas show up in the gutter on the left)..that allows me to render a >> 'color' for an event without re-running the evaluation expression. >> >> I think that's an implementation detail and doesn't need to be in the >> interface, but that's the one place in Chainsaw where the 'core' logging >> event wasn't sufficient. >> >> > To be honest, I've never used Chainsaw. However, my understanding is that > Lillith (for Logback) is similar to it. I don't know how Lillith handles > that but since it is a separate project from Logback I know that isn't > included in the logging event, which makes me wonder how they are handling > that - or if it does. > > Ralph >
