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.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
