log4j 2.0 development (was Re: Sequence number for LoggingEvent)

[Curt Arnold <ca...@apache.org>]

On Dec 9, 2007, at 11:55 AM, Jess Holle wrote:

> Paul Duffy wrote:
>>> For the big picture:
>>>
>>> log4j 2.0 intends to target Java 5 and later and follow modern  
>>> concurrency best practices, but currently it is only a concept and  
>>> some very early experimental code.  While I'd love to flesh out  
>>> the framework and energize a team to built it, keeping log4j 1.2  
>>> running and getting log4cxx is taking all my open source cycles at  
>>> the moment and nobody seems anxious to work on it.
>> Looks like we'll be modifying 1.2 then.  Adding the sequence  
>> number, compiling under 1.6, etc.
> We've not yet gotten to this point in our use of log4j, but may well  
> soon as well -- i.e. to the point that we manage our own fork of 1.2.
>
> In our case this is not for sequence number initially (though that  
> would be nice -- we use an AtomicLong to number our JMX  
> notifications, for instance).  Rather we may well need to make some  
> substantive alterations to the synchronization strategy in log4j.   
> Sure this may break things, but there comes a point where removing  
> synch bottlenecks is more important than maintaining compatibility  
> with stuff you're not using :-)  On the flip side maintaining API  
> compatibility with "typical" log4j call-site (vs. extension) usage  
> is still critical from my standpoint in any case -- else you might  
> as well switch logging frameworks entirely.
>


Right now the "definition" of log4j 2.0 is very open.  The essential  
aspects are:

a) redesigned for concurrency and modern best practices.
b) Targets Java 5 and later.  Earlier JDK's can continue to use log4j  
1.x.
b) finer grain concurrency minimizing locks currently used by log4j 1.x.
c) typical call-site compatibility, but not constrained to be  
extension compatible with log4j 1.2 or rigorously compatible with  
nuances of current log4j 1.2 behavior.

Anything that is released as a log4j 1.x must preserve very strict  
compatibility with earlier log4j releases.  log4j 1.3 was problematic  
in that it wasn't strictly compatible with log4j 1.2 and didn't  
address the concurrency issues so it wasn't a good fit with the log4j  
2.0 goals.  It also wasn't compelling enough to relabel it as log4j  
2.0 and then have a log4j 3.0 that addressed the concurrency issues.

I've put some personal experiments on log4j 2.0 themes in the sandbox,  
but they aren't binding on the community and the eventual log4j 2.0  
development may or may not incorporate them.  If you are motivated  
enough to fork log4j 1.2 to work on the concurrency issues, then it  
would be great if we could find a way that you could work inside the  
community and in the open with others who share the same concerns.   
I'd have little problem with setting up branches in the SVN for any  
number of experiments that might lead to log4j 2.0.  If a few failed  
or were abandoned while other flourished, that is the nature of  
experiments.  The only problem would be code that was developed in  
isolation from the community (for example, if you branched log4j,  
redesigned a lot of things without discussion and presented it as a  
completed work), then it would need to go through the incubator if the  
community thought that it was worth the effort.

Any proposals for will be seriously considered.  If you are  
interested, I'd suggest that you reread previous log4j 2.0 threads and  
ask any questions you have.   I think we'd all like to see log4j 2.0  
development moving, but it is going to be the people who are suffering  
from log4j 1.x shortcomings who are going to be motivated to drive  
log4j 2.0 development.  I don't think anyone is picky about how it  
happens other than it happens in the Apache way.


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