Curt Arnold wrote:
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.
For a 1.4.x or 2.0.x, I'm not so concerned about breaking extensions.
I'm more concerned about breaking "application" code -- i.e. use of the
logging APIs for logging and for configuration thereof, including
sophisticated code that adds hierarchy listeners, uses logger repository
selectors, etc, but not including custom appenders, layouts, etc. I
would hope that any really worthwhile extensions would be ported by
someone and could be upgraded along with log4j as needed, whereas
application code is unlikely to be so malleable. I realize the
distinction is somewhat arbitrary and I could understand some of the
more sophisticated (weird?) application usages breaking as long as there
was a suitable replacement for the old functionality that was broken in
the process. "Normal" usage of log4j APIs that most applications stick
to should not be broken, however.
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.
That's a good question. Version #'s are cheap, so in this regard, I'd
suggest such increment improvements go into a 1.4.x, so no one gets
upset when they find that some new 1.2.x version is not compatible with
the same ancient JVMs as 1.2.14 was -- unless, of course, the given
incremental improvement does not break such compatibility (either
outright or by producing a behavioral/performance regression in such old
JVMs).
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.
In the case where one has something strictly insisting on log4j 1.2.x
(and breaking with 2.0.x) and something requiring 2.0.x that you want in
the same classloader, you're absolutely right, of course. Do we feel
that this use case is likely? If so, we should do as you say.
What I'm looking for is that the 90% usage case, i.e. most of the
methods of Logger, Level, and a few other critical classes, remain "as
is" -- that could be done via a "shim" as you put it. One could provide
a shim. If the key "90% case" APIs are kept "as is" except under a
different package name, then a simple mass replace could convert source
code and remove need for the shim. The shim could still be useful for
interaction with old libraries to which you had no source (or no desire
to rebuild) in many cases, though -- i.e. many libraries wouldn't use
enough APIs or use log4j extensively enough to know the difference.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
