[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-user
Subject:    Re: Multithreading issues - doAppend is synchronised?
From:       Curt Arnold <carnold () apache ! org>
Date:       2009-11-08 22:29:02
Message-ID: B588B27B-DF2E-4CB8-BA8E-A5BA502F05C3 () apache ! org
[Download RAW message or body]


On Nov 8, 2009, at 2:18 PM, Pat Farrell wrote:

> Curt Arnold wrote:
>> Unfortunately, log4j 1.2 was designed in a era where concurrency  
>> was not
>> as significant a concern.
>
> As was typical of Java at the time.
>
> The times have changed.
>
>> There has been a desire, but no active development, for a log4j 2.0  
>> that
>> was designed for concurrency, JDK 5 and the all good things while  
>> having
>> a simple migration path for log4j 1.2 users.  However, there has  
>> never
>> been the critical mass of developers ready at the same time to make  
>> a go
>> at it.
>
> How far did this effort go? How close are/were you to the critical  
> mass.
> I'm very interested in this, and if its close, might be able to help.
>
> -- 
> Pat Farrell
> http://www.pfarrell.com/

There is a bug repo for log4j 2.0 that collects design goals, wish  
lists, ideas for log4j 2.0 at https://issues.apache.org/jira/browse/LOG4J2

Code-wise, I did some exploratory stuff several years ago around the  
back-end classes at http://svn.apache.org/repos/asf/logging/sandbox/experimental/pattern-layout 
.  The big ideas were to have an extract phase that collected  
invariant values from the logging context (that much had to be  
synchronized) and logging call and then everything else worked off the  
collected values and that the same back-end classes (appenders,  
layout, etc) should be independent from the logging API  
(java.util.logging, org.apache.log4j, etc).

Community wise, about a year ago we added an authorization class for  
log4j 2.0 development (no rights on 1.2 code base) and granted it to  
an existing ASF committer (Ralph Goers) who was interested in pitching  
in.

There is a bit of a chicken and egg syndrome at work.  I didn't  
proceed to flesh out a log4j 2.0 framework back in the day since  
without a community to review as it was being developed, it would be  
just one guys take on the problem.  However without at least a  
skeletal code base, it is hard for somebody to jump in and help out.

The mailing list archive has a lot of discussion on what log4j 2.0  
should look like if you up for mailing list archaeology.


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

[prev in list] [next in list] [prev in thread] [next in thread]