Elias, you are proposing that there be a new/different set of "concurrent"
appenders? One that do not suffer from the problem that has been
identified?
-Mark
----- Original Message -----
From: "Elias Ross" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[email protected]>
Cc: "Curt Arnold" <[EMAIL PROTECTED]>
Sent: Friday, December 23, 2005 4:37 PM
Subject: Re: log4j 1.3 prioritized tasks
On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
I'd prefer to expedite the 2.0 branch and get log4j using a much
finer grained locking than maintaining two parallel sets of appenders
with different locking characteristics.
I'd be happy to help expedite a 2.0 release, but it seems ever further
away. And I anticipate (in six months) you'll find yourself in a
similarly unpleasant situation for 2.0 where people demand application
binary compatibility.
It's also likely people are going to want both styles of appenders. You
Joe Java coder might not understand (or want to learn about) read/write
locking rules.
A good analogy is how the new JDK 1.5 java.util.concurrent.* collection
classes did not deprecate existing locked collections classes, nor were
java.util.Vector or java.util.Hashtable considered for removal.
The concurrent library I proposed is around 1000 lines of new
code/comments to maintain, compared to about 44,000 lines total for the
existing log4j code base. Frankly, all I would like from the log4j is
an endorsement and place in svn, I can maintain and deal with the
implementation details.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
