logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: 1.3 - A Line in the Sand
Date Tue, 03 Apr 2007 14:33:06 GMT
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:

   1. Has finer-grained synchronization and eliminates some
      possibilities that currently exist for deadlocks, etc.
   2. 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.

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.

--
Jess Holle

P.S. Okay, the ability to add a listener to a repository for log level 
changes (as per log4j 1.3's last iterations) would be really nice.  I'm 
not against added bits like this.

Noel Grandin wrote:
> Hi
>
> I'm just an end-user of log4j, so I have no perspective on the internal
> dev issues.
>
> But from the POV of a programmer who uses log4j in many projects, I have
> to say that it's pretty great the way it is!!
>
> It may simply be that log4j as it currently stands is good enough for
> the vast majority of projects, hence the lack of interest in improving it.
>
> I like log4j - it's pretty clean, robust, easy to use, and doesn't have
> vast quantities of complexities for corner cases that most people never see.
>
> Regards and thanks for the great work!
>  -- Noel Grandin
>
> Disclaimer: http://www.peralex.com/disclaimer.html


Mime
View raw message