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).


 * 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);


On Mon, Feb 6, 2012 at 11:16 AM, ralph.goers @dslextreme.com <ralph.goers@dslextreme.com> wrote:

On Mon, Feb 6, 2012 at 11:00 AM, Scott Deboy <scott.deboy@gmail.com> 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.