logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: 1.3 - A Line in the Sand
Date Tue, 03 Apr 2007 21:34:06 GMT

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  

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message