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.
Seems several of us are heading this way.
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 :-)
Absolutely.
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.
Agreed
--
Jess Holle
---------------------------------------------------------------------
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]
