Latest changes to ant script

[Scott Deboy <sd...@comotivsystems.com>]

(for those who didn't see the commit msg:)
I've modified the chainsaw.jar target to not fail when the ORO jar is not present.

If the location of the ORO jar is not provided in build.properties, a warning message is displayed and the task continues.

The chainsaw jar is created, excluding (because they rely on ORO):
   LikeRule
   LogFilePatternReceiver 
------------------------------------------------
Other build/code organization issues:

ExpressionFilter and rule package

ExpressionFilter is currently available only from the Chainsaw jar, although it's not used by Chainsaw at all.  It's a filter (used with appenders) which provides access to the same rules and expression syntax used to colorize and filter events in Chainsaw.

The rules package (org.apache.log4j.rule) is used by ExpressionFilter as well as Chainsaw, but is currently available only from the Chainsaw jar.

The expression syntax and rules package provide access to all parts of a logging event through keywords, as well as support for:
operators: ==, !=, EXISTS, <, <=, >, >=, LIKE (regexp), ~= (case-insensitive partial text match)
grouping of expressions using boolean operators &&, ||, ! and parentheses

For example, to filter only expressions with the word 'result' or 'timing' in the message, use this expression:
MSG ~= 'result' || MSG ~= 'timing'

Is there interest in moving these files (ExpressionFilter and the rule package) from the chainsaw jar to the core jar?  

They provide a great amount of flexibility in filtering and I've been working recently to make sure their performance is on-par with the existing filters in the sandbox.  

Thoughts?

Re: Latest changes to ant script

[Jacob Kjome <ho...@visi.com>]

Quoting Scott Deboy <sd...@comotivsystems.com>:

> (for those who didn't see the commit msg:)
> I've modified the chainsaw.jar target to not fail when the ORO jar is not
> present.
>
> If the location of the ORO jar is not provided in build.properties, a warning
> message is displayed and the task continues.
>

I find this a little odd.  IMO, if any dependency is not available, the build
should fail.  Think of the case where a developers build the jars themselves
and then report errors saying that such and such isn't working.  Well, it then
turns out that they didn't have a full jar because they didn't make some
dependencies available at build time.  I think it should fail with a clear
message saying what dependency is missing.  More below on this...


> The chainsaw jar is created, excluding (because they rely on ORO):
>    LikeRule
>    LogFilePatternReceiver
> ------------------------------------------------
> Other build/code organization issues:
>
> ExpressionFilter and rule package
>
> ExpressionFilter is currently available only from the Chainsaw jar, although
> it's not used by Chainsaw at all.  It's a filter (used with appenders) which
> provides access to the same rules and expression syntax used to colorize and
> filter events in Chainsaw.
>
> The rules package (org.apache.log4j.rule) is used by ExpressionFilter as well
> as Chainsaw, but is currently available only from the Chainsaw jar.
>
> The expression syntax and rules package provide access to all parts of a
> logging event through keywords, as well as support for:
> operators: ==, !=, EXISTS, <, <=, >, >=, LIKE (regexp), ~= (case-insensitive
> partial text match)
> grouping of expressions using boolean operators &&, ||, ! and parentheses
>
> For example, to filter only expressions with the word 'result' or 'timing' in
> the message, use this expression:
> MSG ~= 'result' || MSG ~= 'timing'
>
> Is there interest in moving these files (ExpressionFilter and the rule
> package) from the chainsaw jar to the core jar?
>

What is our policy on runtime dependencies?  I can undertand Chainsaw having
runtime dependencies, but I'm not sure how valid this is for Log4j itself. 
Maybe we could treat this like Ant does and keep classes with third party
dependencies outside of the core.  Just distribute them as a separate,
optional, jar.


> They provide a great amount of flexibility in filtering and I've been working
> recently to make sure their performance is on-par with the existing filters
> in the sandbox.
>
> Thoughts?
>

Making them available is a good idea, but probably as a separate jar.


Jake






---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org