Apache Logging General Mailing List

Ralph Goers | 6 Feb 2012 00:02

Log4J 2

As you may be aware I have been working on Log4j 2 for about 2 years now.  It now consists of a fairly large body of
code with fairly decent documentation. I feel it is ready to come out of my experimental branch and onto its
own main branch where others will hopefully feel more inclined to participate.  Although this shouldn't
surprise anyone and I could probably do this without forewarning, I consider it good manners to give
adequate notice.

Ralph

headers

Christian Grobmeier | 6 Feb 2012 00:04

Re: Log4J 2

Yay, this are great news!!!!
Congratulations! On the hard work, on the outcome and that you didn't
give up! Welcome to the main branch 

Cheers!

On Mon, Feb 6, 2012 at 12:02 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> As you may be aware I have been working on Log4j 2 for about 2 years now.  It now consists of a fairly large
body of code with fairly decent documentation. I feel it is ready to come out of my experimental branch and
onto its own main branch where others will hopefully feel more inclined to participate.  Although this
shouldn't surprise anyone and I could probably do this without forewarning, I consider it good manners to
give adequate notice.
>
> Ralph

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

headers

Stefan Bodewig | 6 Feb 2012 10:10

Re: Log4J 2

On 2012-02-06, Ralph Goers wrote:

> As you may be aware I have been working on Log4j 2 for about 2 years
> now.  It now consists of a fairly large body of code with fairly
> decent documentation. I feel it is ready to come out of my
> experimental branch and onto its own main branch where others will
> hopefully feel more inclined to participate.

For the benefit of the log4(X != j) communities, can you give some sort
of elevator pitch for log4j 2.0?  What is different?  Given that the
other projects around here have followed the 1.x model, it will be good
to know what you considered good or bad of the "old" approach.

Don't hesitate to send me to some sort of overview document, I admit I
haven't looked for one, yet.

Thanks

        Stefan

headers

Christian Grobmeier | 6 Feb 2012 10:24

Re: Log4J 2

On Mon, Feb 6, 2012 at 10:10 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:
> On 2012-02-06, Ralph Goers wrote:
>
>> As you may be aware I have been working on Log4j 2 for about 2 years
>> now.  It now consists of a fairly large body of code with fairly
>> decent documentation. I feel it is ready to come out of my
>> experimental branch and onto its own main branch where others will
>> hopefully feel more inclined to participate.
>
> For the benefit of the log4(X != j) communities, can you give some sort
> of elevator pitch for log4j 2.0?  What is different?  Given that the
> other projects around here have followed the 1.x model, it will be good
> to know what you considered good or bad of the "old" approach.
>
> Don't hesitate to send me to some sort of overview document, I admit I
> haven't looked for one, yet.

Great idea, could use that too. With the approaching ApacheCon EU I
think it would be a great talk there.

Cheers
Christian

> Thanks
>
>        Stefan

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

(Continue reading)

headers

Ralph Goers | 6 Feb 2012 17:56

Re: Log4J 2

On Feb 6, 2012, at 1:10 AM, Stefan Bodewig wrote:

On 2012-02-06, Ralph Goers wrote:

As you may be aware I have been working on Log4j 2 for about 2 years

now. It now consists of a fairly large body of code with fairly

decent documentation. I feel it is ready to come out of my

experimental branch and onto its own main branch where others will

hopefully feel more inclined to participate.

For the benefit of the log4(X != j) communities, can you give some sort
of elevator pitch for log4j 2.0? What is different? Given that the
other projects around here have followed the 1.x model, it will be good
to know what you considered good or bad of the "old" approach.

Don't hesitate to send me to some sort of overview document, I admit I
haven't looked for one, yet.

You can find the latest documentation at http://people.apache.org/~rgoers/log4j2/

Ralph

headers

Scott Deboy | 6 Feb 2012 18:40

Re: Log4J 2

Is support for the concept of an event sink (receivers) going to be straightforward to implement using log4j2's configuration support?

I just want to make sure we are covering our bases there. It would be great to have explicit support for receivers, the same as we have for appenders.

For the socketappender, can it be configured to be multicast? If so, it would be good to be able to provide in the interface that was going to be used.

There are of course other appenders (the reverse-connect sockethubappender, for example), and the other network-based appenders which can probably be replaced by this single socket appender if it were beefed up a bit.

Scott

On Mon, Feb 6, 2012 at 8:56 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:

On Feb 6, 2012, at 1:10 AM, Stefan Bodewig wrote:

On 2012-02-06, Ralph Goers wrote:

As you may be aware I have been working on Log4j 2 for about 2 years

now. It now consists of a fairly large body of code with fairly

decent documentation. I feel it is ready to come out of my

experimental branch and onto its own main branch where others will

hopefully feel more inclined to participate.

For the benefit of the log4(X != j) communities, can you give some sort
of elevator pitch for log4j 2.0? What is different? Given that the
other projects around here have followed the 1.x model, it will be good
to know what you considered good or bad of the "old" approach.

Don't hesitate to send me to some sort of overview document, I admit I
haven't looked for one, yet.

You can find the latest documentation at http://people.apache.org/~rgoers/log4j2/

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 19:14

Re: Log4J 2

On Mon, Feb 6, 2012 at 9:40 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

Is support for the concept of an event sink (receivers) going to be straightforward to implement using log4j2's configuration support?

I just want to make sure we are covering our bases there. It would be great to have explicit support for receivers, the same as we have for appenders.

While it isn't there now I don't see any reason it couldn't be added. I've implemented a couple of standalone servers but not integrated with the configuration. It would require a change to BaseConfiguration and we would need a Receiver interface - is there one? I'm pretty sure they would need to use Managers just as the Appenders to so that they can survive a reconfiguration.

For the socketappender, can it be configured to be multicast? If so, it would be good to be able to provide in the interface that was going to be used.

I haven't programmed multicast recently but my recollection was that it isn't too different. I don't see why it couldn't be supported.

There are of course other appenders (the reverse-connect sockethubappender, for example), and the other network-based appenders which can probably be replaced by this single socket appender if it were beefed up a bit.

There is still a lot of work to do. I've not implemented a DB Appender, JMX support, OSGi support but I believe the foundation is there for them. Logback supports XML and Groovy as configuration mechanisms. Currently, Log4j 2 currently supports XML and JSON. I've not convinced myself why using a DSL is a good thing but it should be easy to add if desired.

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 19:23

Re: Log4J 2

On Mon, Feb 6, 2012 at 9:40 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

Is support for the concept of an event sink (receivers) going to be straightforward to implement using log4j2's configuration support?

I just want to make sure we are covering our bases there. It would be great to have explicit support for receivers, the same as we have for appenders.

For the socketappender, can it be configured to be multicast? If so, it would be good to be able to provide in the interface that was going to be used.

There are of course other appenders (the reverse-connect sockethubappender, for example), and the other network-based appenders which can probably be replaced by this single socket appender if it were beefed up a bit.

SocketAppender itself doesn't do much. It is really an OutputStreamAppender that leverages a SocketManager. At the moment it supports a TCPSocketManager and a DatagramSocketManager. Adding other types of SocketManagers doesn't require much.

Ralph

headers

Scott Deboy | 6 Feb 2012 19:35

Re: Log4J 2

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

Scott

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

On Mon, Feb 6, 2012 at 9:40 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

Is support for the concept of an event sink (receivers) going to be straightforward to implement using log4j2's configuration support?

I just want to make sure we are covering our bases there. It would be great to have explicit support for receivers, the same as we have for appenders.

For the socketappender, can it be configured to be multicast? If so, it would be good to be able to provide in the interface that was going to be used.

There are of course other appenders (the reverse-connect sockethubappender, for example), and the other network-based appenders which can probably be replaced by this single socket appender if it were beefed up a bit.

SocketAppender itself doesn't do much. It is really an OutputStreamAppender that leverages a SocketManager. At the moment it supports a TCPSocketManager and a DatagramSocketManager. Adding other types of SocketManagers doesn't require much.

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 19:50

Re: Log4J 2

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

Can you point me to the expression/expressionfilter support you are talking about? I don't recall seeing that in Log4j's code base. The filters I've implemented to this point are documented at http://people.apache.org/~rgoers/log4j2/manual/filters.html.

Logback also supports "evaluators". I've thought about that but the only difference seems to be that Filters return ACCEPT, DENY or NEUTRAL while evaluators are boolean. If I did that I would expect that most of the logic in the current filters would be moved to an Evaluator and then the individual filters would extend an EvaluatorFilter.

With all that, any ideas you have like that are certainly welcome. Take a look at the documentation and the code. My hope was to make things fairly amenable to enhancements.

Ralph

headers

Scott Deboy | 6 Feb 2012 19:57

Re: Log4J 2

Here is the Chainsaw tutorial html page which describes expression support:

http://svn.apache.org/viewvc/logging/chainsaw/trunk/src/main/resources/org/apache/log4j/chainsaw/help/tutorial.html?revision=1032218&view=co

One thing to note is it makes all fields (including properties/mdc) available in expressions, which can be pretty useful, since you can now write a regexp against any field, not just the message.

One other thing to note, I've updated the network appender in log4j 1.2 to support ZeroConf out of the box via reflection if it's available..I think that's a useful feature (Chainsaw supports it).

Scott

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

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

Can you point me to the expression/expressionfilter support you are talking about? I don't recall seeing that in Log4j's code base. The filters I've implemented to this point are documented at http://people.apache.org/~rgoers/log4j2/manual/filters.html.

Logback also supports "evaluators". I've thought about that but the only difference seems to be that Filters return ACCEPT, DENY or NEUTRAL while evaluators are boolean. If I did that I would expect that most of the logic in the current filters would be moved to an Evaluator and then the individual filters would extend an EvaluatorFilter.

With all that, any ideas you have like that are certainly welcome. Take a look at the documentation and the code. My hope was to make things fairly amenable to enhancements.

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 19:55

Re: Log4J 2

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

headers

Scott Deboy | 6 Feb 2012 20:00

Re: Log4J 2

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 <at> dslextreme.com <ralph.goers <at> dslextreme.com> wrote:

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

headers

Scott Deboy | 6 Feb 2012 20:12

Re: Log4J 2

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 <scott.deboy <at> 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.

Scott

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

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

headers

ralph.goers @dslextreme.com | 6 Feb 2012 20:24

Re: Log4J 2

On Mon, Feb 6, 2012 at 11:12 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

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/

Thanks. I'll take a look at these tonight. I thought I looked through companions at some point looking for stuff to pull in. This just may not have been obvious or I might have decided (perhaps incorrectly) that the RegexFilter provided similar functionality.

If these do what I think it might make more sense to leverage Java 5/6's ability to leverage scripting languages in a Filter. I've thought about doing that anyway.

Ralph

headers

Scott Deboy | 6 Feb 2012 20:29

Re: Log4J 2

This is where a DSL is slightly handy, in order to keep the syntax pretty compact and readable...but, as I mentioned, there are limitations (building an 'around' operator is probably tricky).

Scott

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

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

Thanks. I'll take a look at these tonight. I thought I looked through companions at some point looking for stuff to pull in. This just may not have been obvious or I might have decided (perhaps incorrectly) that the RegexFilter provided similar functionality.

If these do what I think it might make more sense to leverage Java 5/6's ability to leverage scripting languages in a Filter. I've thought about doing that anyway.

Ralph

headers

Scott Deboy | 6 Feb 2012 20:32

Re: Log4J 2

Also, don't forget soundappender! ha

On Mon, Feb 6, 2012 at 11:29 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

This is where a DSL is slightly handy, in order to keep the syntax pretty compact and readable...but, as I mentioned, there are limitations (building an 'around' operator is probably tricky).

Scott

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

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

Thanks. I'll take a look at these tonight. I thought I looked through companions at some point looking for stuff to pull in. This just may not have been obvious or I might have decided (perhaps incorrectly) that the RegexFilter provided similar functionality.

If these do what I think it might make more sense to leverage Java 5/6's ability to leverage scripting languages in a Filter. I've thought about doing that anyway.

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 20:34

Re: Log4J 2

On Mon, Feb 6, 2012 at 11:32 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

Also, don't forget soundappender! ha

I'm sorry, did you say something? ;-)

Ralph

headers

ralph.goers @dslextreme.com | 6 Feb 2012 20:16

Re: Log4J 2

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

Ralph

headers

Scott Deboy | 6 Feb 2012 20:20

Re: Log4J 2

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.
*
* <at> param e LoggingEvent this instance will evaluate
* <at> 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
* <at> 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 <at> dslextreme.com <ralph.goers <at> dslextreme.com> wrote:

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

Ralph

headers

Scott Deboy | 6 Feb 2012 20:22

Re: Log4J 2

Lilith probably isn't anything log4j-related to support queries etc. A lot of what I use in Chainsaw is available in log4j or the companions.

Scott

On Mon, Feb 6, 2012 at 11:20 AM, Scott Deboy <scott.deboy <at> gmail.com> wrote:

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.
*
* <at> param e LoggingEvent this instance will evaluate
* <at> 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
* <at> 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 <at> dslextreme.com <ralph.goers <at> dslextreme.com> wrote:

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

Ralph

headers

Mark Struberg | 18 Feb 2012 21:14

Re: Log4J 2


+1 for bringing log4j-2.0 to the surface of the earth :)

LieGrue,
strub

>________________________________
> From: Ralph Goers <ralph.goers <at> dslextreme.com>
>To: Logging General <general <at> logging.apache.org> 
>Cc: Log4J Developers List <log4j-dev <at> logging.apache.org> 
>Sent: Monday, February 6, 2012 5:56 PM
>Subject: Re: Log4J 2
> 
>
>
>
>On Feb 6, 2012, at 1:10 AM, Stefan Bodewig wrote:
>
>On 2012-02-06, Ralph Goers wrote:
>>
>>
>>As you may be aware I have been working on Log4j 2 for about 2 years
>>>
>>now.  It now consists of a fairly large body of code with fairly
>>>
>>decent documentation. I feel it is ready to come out of my
>>>
>>experimental branch and onto its own main branch where others will
>>>
>>hopefully feel more inclined to participate.
>>>
>>For the benefit of the log4(X != j) communities, can you give some sort
>>of elevator pitch for log4j 2.0?  What is different?  Given that the
>>other projects around here have followed the 1.x model, it will be good
>>to know what you considered good or bad of the "old" approach.
>>
>>Don't hesitate to send me to some sort of overview document, I admit I
>>haven't looked for one, yet.
>>
>
>You can find the latest documentation at http://people.apache.org/~rgoers/log4j2/
>
>
>Ralph
>
>

headers

Ralph Goers | 19 Feb 2012 00:11

Re: Log4J 2

Thanks - I moved the code to https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk.

Ralph

On Feb 18, 2012, at 12:14 PM, Mark Struberg wrote:

> 
> 
> +1 for bringing log4j-2.0 to the surface of the earth :)
> 
> LieGrue,
> strub
> 
> 
> 
> 
>> ________________________________
>> From: Ralph Goers <ralph.goers <at> dslextreme.com>
>> To: Logging General <general <at> logging.apache.org> 
>> Cc: Log4J Developers List <log4j-dev <at> logging.apache.org> 
>> Sent: Monday, February 6, 2012 5:56 PM
>> Subject: Re: Log4J 2
>> 
>> 
>> 
>> 
>> On Feb 6, 2012, at 1:10 AM, Stefan Bodewig wrote:
>> 
>> On 2012-02-06, Ralph Goers wrote:
>>> 
>>> 
>>> As you may be aware I have been working on Log4j 2 for about 2 years
>>>> 
>>> now.  It now consists of a fairly large body of code with fairly
>>>> 
>>> decent documentation. I feel it is ready to come out of my
>>>> 
>>> experimental branch and onto its own main branch where others will
>>>> 
>>> hopefully feel more inclined to participate.
>>>> 
>>> For the benefit of the log4(X != j) communities, can you give some sort
>>> of elevator pitch for log4j 2.0?  What is different?  Given that the
>>> other projects around here have followed the 1.x model, it will be good
>>> to know what you considered good or bad of the "old" approach.
>>> 
>>> Don't hesitate to send me to some sort of overview document, I admit I
>>> haven't looked for one, yet.
>>> 
>> 
>> You can find the latest documentation at http://people.apache.org/~rgoers/log4j2/
>> 
>> 
>> Ralph
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe <at> logging.apache.org
> For additional commands, e-mail: log4j-dev-help <at> logging.apache.org
>