On Apr 3, 2007, at 9:33 AM, Jess Holle wrote:
Largely I won't disagree.
That said, I think there is a point to having a new log4j version
that is almost entirely API (source and binary) compatible with
log4j 1.2.14, but:
Has finer-grained synchronization and eliminates some possibilities
that currently exist for deadlocks, etc.
Uses modern JVM features to reduce scalability bottlenecks, etc.
I think log4j 1.2.14 is "as good as it gets" (or needs to) for JVMs
up to Java 1.4, but that there should be a compatible option that
is optimized for Java 5 and higher (or at least assumes good
ThreadLocal, etc, and takes advantage of these at a bare minimum).
When I say "almost entirely" I mean API compatible wherever
possible while attaining item #1 above at least. This may break
some extensions (3rd-party appenders, etc), but that seems like a
reasonable price to pay. These can be updated (as long as what's
needed to do so is clearly spelled out) or those needing them can
stay at 1.2.14.
Any rework that addressed the synchronization and scalability issues
would almost certainly break the (largely implied) contracts that
extension appenders, layouts, etc depend upon. log4j 1.2.x made
little or no attempts to control where log4j could be extended: very
few classes if any are final and the implementation details are
visible, and so anything but small feature additions can break some
potential extension. I would expect that any attempt to address the
synchronization issues would abandon any attempt to be compatible
with existing extensions but could provide a shim that could be used
to emulate the "client" portions of the log4j 1.2.x API.
Use of ThreadLocal and other incremental improvements could be done
in a log4j 1.x, but I don't know whether we'd want to do that as a
1.2.x or a log4j 1.4.
Why the insistence on API compatibility? This would allow the vast
majority of developers to simply code for "log4j" and ignore 1.2.x
vs. 1.3.x or 2.0.x distinctions and thus avoids fracturing log4j's
mindshare. Instead deployers could simply decide on the version of
log4j that best met their needs, e.g. old JVM compatible or not, etc.
Not sure I'm following. If a version implies compatibility with a
previous version (only a minor revision in version number and same
package names), then breaking existing clients that were perfectly
legal and function with the earlier versions is extremely bad form.
See http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs.
Basically for log4j 2.0, I think that we are left with the "start
over in a new package" approach. However, we could provide shim with
a emulation of a subset of the old API that could be used at the
client's own risk.
On Apr 3, 2007, at 12:03 PM, Gary Gregory wrote:
We currently use 1.3 Alpha-7 and it works pretty well for us, my
preference as a user would be to clean up the current alpha for
release as 1.3 or call it 2.0 if it is not binary compatible with
the latest 1.2.14.
Rebranding log4j 1.3 as log4j 2.0 and then having log4j 3.0 as the
designed for JDK 1.5+ and fine grained concurrency release was toyed
with a few years ago, but the consensus was that log4j could only
pull off one big API incompatible release and not two successive
ones. Would be interesting to know what features you are using in
log4j 1.3 and whether they could be backported to log4j 1.2.
In general, I dislike "big bang" releases and favor instead release
early, release often, a la XP.
Unfortunately, log4j 1.3 development proceed for a substantial amount
of time with little concern with compatibility with compatibility
with log4j 1.2 and the primary developer of log4j 1.3 has left for
other projects. We are left trying to remedy the situation we are
in. There have definitely been incremental releases in the log4j
1.2.x branch and may continue to be so, but the code is very dated
and extremely difficult to modify without potential compatibility
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
