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: log4j 1.3 prioritized tasks
Date Sat, 24 Dec 2005 00:10:32 GMT

On Dec 23, 2005, at 3:37 PM, Jacob Kjome wrote:

>
> A bit of a sidetrack from the current discussion, but just how big  
> is log4j-1.3 going to be and just how polluted with 1.2.xx stuff  
> are we going to make it?  Originally, a lot of stuff was refactored  
> and/or removed and replaced by, arguably, better implementations.   
> Last changes I made, I had Log4j-1.3 and Log4j-1.2.xx working with  
> LogWeb.  I figured that if something that uses Log4j internals like  
> LogWeb works with both, then 1.3 was good to go.

My impression was that even the simplest app that used log4j 1.2  
would fail with class verifier exceptions on JDK 1.5 with the current  
log4j 1.3.  I'm sure that the major culprit for that was the Priority/ 
Level inversion and if that was fixed, then only a much smaller sets  
of potential applications would fail.

> Now we've got everything from Log4j-1.2.xx coming back into  
> Log4j-1.3, plus all the changes and additions made for 1.3 in there  
> as well.  From my perspective, maybe the current 1.3 should have  
> just moved to 2.0 and 1.3 should have been developed off the 1.2  
> branch.  1.3 seems to be turning into a monster with everything  
> 1.2.xx being added back in to make it binary compatible.  Log4j is  
> already somewhat bloated as it is.  Any larger and its going to burst.
>
> thoughts?

The biggest thing that would go back in to restore binary  
compatibility in my estimation would be the  
org.apache.log4j.DailyRollingFileAppender and  
org.apache.log4j.RollingFileAppender.  Currently, there are shims  
that redirect to o.a.l.rolling.RollingFileAppender that should be  
sufficient if you only used those classes but would not be compatible  
if you had extended them.  There had been nothing in the 1.2 code  
base that marked those classes as either deprecated or final or  
warned against extension, so not bringing them back would be likely  
to break some legitimate users of log4j 1.2.

There are a couple of options:

a) Totally drop the o.a.l.RFA and DRFA classes

This was tried but there were repeated complaints about configuration  
files that no longer worked with 1.3 that give rise to the shims.

b) Leave the shims in and document that applications that use  
extensions of those classes will break.

c) Replace the shims with the current 1.2 implementations, but mark  
as deprecated and
     1) leave in log4j.jar
     2) place in log4j-deprecated.jar (or similar)

A log4j-deprecated.jar has some appeal since it could be the home of  
a lot of dropped (without warning) classes like o.a.l.HTMLLayout and  
the o.a.l.varia Filters.

Actually, a bigger thing to go back for strict compatibility would be  
LogFactor5 which is still part of the log4j-1.2.x.jar's.  However, I  
think it would be likely that we could get away with saying that any  
app that used LF5 will break with log4j 1.3.

p.s.: As for wanting binary compatibility or a lean and mean log4j.   
I actually want both, a compatible 1.3 and a lean and mean 2.0.  I  
want the mean and lean 2.0 more, but think the best path first makes  
the current code base 1.2 compatible and then consider intentional  
and radical changes to the implementation but under a different  
package name.

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


Mime
View raw message