headers
Ralph Goers | 6 Feb 2012 00:02
Favicon

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
Permalink | Reply | 22 comments |
headers
Christian Grobmeier | 6 Feb 2012 00:04
Picon
Gravatar

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
Permalink | Reply | 0 comments |
headers
Stefan Bodewig | 6 Feb 2012 10:10
Picon
Favicon
Gravatar

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
Permalink | Reply | 20 comments |
headers
Christian Grobmeier | 6 Feb 2012 10:24
Picon
Gravatar

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)

Permalink | Reply | 0 comments |
headers
Ralph Goers | 6 Feb 2012 17:56
Favicon

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
Permalink | Reply | 18 comments |
headers
Scott Deboy | 6 Feb 2012 18:40
Picon

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

Permalink | Reply | 15 comments |
headers
ralph.goers @dslextreme.com | 6 Feb 2012 19:14
Favicon

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

Ralph 
Permalink | Reply | 0 comments |
headers
ralph.goers @dslextreme.com | 6 Feb 2012 19:23
Favicon

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
Permalink | Reply | 13 comments |
headers
Scott Deboy | 6 Feb 2012 19:35
Picon

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

Permalink | Reply | 12 comments |
headers
ralph.goers @dslextreme.com | 6 Feb 2012 19:50
Favicon

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
Permalink | Reply | 1 comment |

Gmane