Return-Path: X-Original-To: apmail-logging-general-archive@www.apache.org Delivered-To: apmail-logging-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E0C1E99EF for ; Mon, 6 Feb 2012 19:12:38 +0000 (UTC) Received: (qmail 49165 invoked by uid 500); 6 Feb 2012 19:12:38 -0000 Delivered-To: apmail-logging-general-archive@logging.apache.org Received: (qmail 49031 invoked by uid 500); 6 Feb 2012 19:12:37 -0000 Mailing-List: contact general-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Logging General" List-Id: Delivered-To: mailing list general@logging.apache.org Received: (qmail 49023 invoked by uid 99); 6 Feb 2012 19:12:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 19:12:37 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of scott.deboy@gmail.com designates 209.85.217.175 as permitted sender) Received: from [209.85.217.175] (HELO mail-lpp01m020-f175.google.com) (209.85.217.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Feb 2012 19:12:30 +0000 Received: by lbol12 with SMTP id l12so1669691lbo.34 for ; Mon, 06 Feb 2012 11:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h8m2b7Rd7f2m7xPBxF31S5pbFyP3KblisKcW6DonMBY=; b=rV1Uqf6WBSsaEE/oSAHeR8uwq0/gZzSqNIc+x4UBNWfV0kq8KN+GQSBdG86cmnYSUI jpj5Q0gKPTynhTcgLdVmMlBlIgKlWqTNinXKhtN13sRrUEG43T1hWTBQGLIKsiDjINlL 9I/yogLB5/msYPgj5WwmqMxG5CV++666lWr4E= MIME-Version: 1.0 Received: by 10.112.87.234 with SMTP id bb10mr4444938lbb.33.1328555530495; Mon, 06 Feb 2012 11:12:10 -0800 (PST) Received: by 10.112.20.231 with HTTP; Mon, 6 Feb 2012 11:12:10 -0800 (PST) In-Reply-To: References: <69B35595-4446-4168-83D9-DA9BD21B4F85@dslextreme.com> <87k4401g5v.fsf@v35516.1blu.de> <3D7193B6-1F8F-483D-918C-87DED73EC5D4@dslextreme.com> Date: Mon, 6 Feb 2012 11:12:10 -0800 Message-ID: Subject: Re: Log4J 2 From: Scott Deboy To: Logging General Content-Type: multipart/alternative; boundary=f46d0401fced75a8ac04b85070e5 X-Virus-Checked: Checked by ClamAV on apache.org --f46d0401fced75a8ac04b85070e5 Content-Type: text/plain; charset=ISO-8859-1 The 'Rule' interface, RuleFactory and LoggingEventFieldResolver are used to support expressions..simple stuff, but it works...maybe it's time to throw this away completely and leverage a third-party API instead? Rule, RuleFactory http://svn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/java/org/apache/log4j/rule/ ExpressionFilter: http://svn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/java/org/apache/log4j/filter/ LoggingEventFieldResolver: http://svn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/java/org/apache/log4j/spi/ Scott On Mon, Feb 6, 2012 at 11:00 AM, Scott Deboy 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. > > Scott > > > On Mon, Feb 6, 2012 at 10:55 AM, ralph.goers @dslextreme.com < > ralph.goers@dslextreme.com> wrote: > >> >> >> On Mon, Feb 6, 2012 at 10:35 AM, Scott Deboy wrote: >> >>> I wouldn't mind getting rid of the implementation behind the current >>> expression/expressionfilter support (also used in Chainsaw). Were there >>> improvements in that area? >>> >>> The expression support has some limits which I don't love - yes, you >>> can define regexps and use relational and logical operators and grouping, >>> but I would love to be able to have something like an 'around' operator >>> that would work off of either of events (ten events around a warning >>> message), and/or a time-based version (events within +- 1 minute of a >>> warning message). >>> >>> >> Oh - and I haven't ported chainsaw into Log4j2. When that happens I >> expect it will be a new module. >> >> Ralph >> > > --f46d0401fced75a8ac04b85070e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The 'Rule' interface, RuleFactory and LoggingEventFieldResolver are= used to support expressions..simple stuff, but it works...maybe it's t= ime to throw this away completely and leverage a third-party API instead?
Rule, RuleFactory
http://s= vn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/java/or= g/apache/log4j/rule/

ExpressionFilter:
http://= svn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/java/o= rg/apache/log4j/filter/

LoggingEventFieldResolver:
h= ttp://svn.apache.org/viewvc/logging/log4j/companions/extras/trunk/src/main/= java/org/apache/log4j/spi/

Scott

On Mon, Feb 6, 2012 at 11:00 AM= , Scott Deboy <scott.deboy@gmail.com> wrote:
Yeah I don't mind doing that work. =A0 One thing that was a slightly si= gnificant 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 delt= as show up in the gutter on the left)..that allows me to render a 'colo= r' 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 'c= ore' logging event wasn't sufficient.

Scott


On Mon, Feb 6, 2012 at 10:55 AM, ralph.goers @dslextreme.com <ralph.goers@dslextreme= .com> wrote:


On Mon, Feb 6, 2012 at 10:35 AM, Sc= ott Deboy <scott.deboy@gmail.com> wrote:
I wouldn't mind getting rid of the implementation behind the current ex= pression/expressionfilter support (also used in Chainsaw).=A0 Were there im= provements in that area?=A0

The expression support has some limits = which I don't love=A0 - yes, you can define regexps and use relational = and logical operators and grouping, but I would love to be able to have som= ething like an 'around' operator that would work off of either of e= vents (ten events around a warning message), and/or a time-based version (e= vents within +- 1 minute of a warning message).


Oh - and I haven&#= 39;t ported chainsaw into Log4j2. =A0When that happens I expect it will be = a new module.

Ralph=A0


--f46d0401fced75a8ac04b85070e5--