Mark Womack wrote:
log4j 2.0 thoughts (these are just thoughts now, don't freak out)
Will break extensions source wise and break binary compatibility.
- fundamental redesign
- reorganize the classes/packages (interfaces vs implementations,
group under packages), get rid of deprecated classes
This may make sense for 2.0, but if the change is to be that dramatic,
the whole set of classes should be moved to another package, e.g.
org.apache.log4j2.
That way libraries which use log4j 1.x can co-exist with those using
2.x. Sure those using 2.x will have to global replace as well as
recompile, but an Ant script could be provided to automate that.
- configuration vs runtime (immutable) objects
- finer grained locking for synchronization
- Serialized version of LoggingEvent supportable across log4j 2.X
versions and other logging services projects
- new package name (log4j2?)
I believe that's a must -- else you pose serious issues to both those
attempting to use log4j 1.x and those attempting to use log4j 2.x --
they'll be stepping on each other in practice otherwise.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
