Re: log4j 1.3 prioritized tasks

[Mark Womack <mw...@apache.org>]

I think that achieving as much binary compatibility with 1.2.X as possible 
should be a big goal for 1.3 (I know I keep saying it).  Easing a transition 
to some of the bigger features/additions will be better for the community.

However, if there are changes that we feel are important enough, but 
requires breaking something, I am for that trade off.  I think there are 
probably some things we could do to make some of those changes easier to 
handle.  However, the wholesale number of changes right now need to be 
addressed.  And the breaking changes need to be documented and passed to the 
user community for feedback before release.

In hindsight, maybe we should have just called it 2.0 and made the really 
big changes.  And I suppose we could still call off 1.3 and just start on 
2.0.  Except that I think that a 2.0 effort is going to be a much bigger 
deal than finishing up 1.3 and getting it out there with the new features we 
already have.  So, I am for cleaning up 1.3, making important changes we 
want to make, getting it out there for folks to use.  Then turning to a 
log4j 2.0 with a new package name and some fundamental rethink on the api's.

Can we start a thread for each of the major compatibility issues/features as 
we start to tackle them?  Maybe preface the subject with "[COMPATIBILITY]" 
and then the area being discussed.  That way we can scope them out a little 
and discuss options better.

-Mark

----- Original Message ----- 
From: "Jacob Kjome" <ho...@visi.com>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Saturday, December 24, 2005 9:39 AM
Subject: Re: log4j 1.3 prioritized tasks


> At 06:10 PM 12/23/2005 -0600, you wrote:
> >
> >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.
> >
>
> Yes, I suppose I can agree with that change.  As desirable as it might 
> seem to try to invert the 1.2 Level/Priority relationship and/or get rid 
> of Priority altogether, it isn't worth the cost.  I just think that 
> Log4j-1.3 was moving toward being leaner/meaner (except for Joran).  The 
> thing is, if we are going to keep what was added to 1.3 and bring back 
> everything from 1.2 that was removed, 1.3 will end up being a monster. 
> I'm not even sure a 1.3 is worth doing if that's going to be the end 
> result?  Why not just develop off the 1.2 branch for this purpose and 
> leave the current 1.3-specific feature set to the 2.0 branch?
>
> >> 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.
> >
>
> Yes, the shims were, for me, the end of the acceptability range.  After 
> that, we almost might as well go back to using Log4j-1.2.xx, leading to 
> the discussion here.
>
> >b) Leave the shims in and document that applications that use
> >extensions of those classes will break.
> >
>
> Which is the point at which we might as well develop off the 1.2 branch, 
> at least for me.
>
> >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.
> >
>
> Not a bad idea, but they'd still need some changes to work with the 
> current Log4j-1.3 base, for instance using internal logging rather than 
> LogLog, and probably a few other changes as well.
>
> >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.
> >
>
> That depends.  If we develop 1.3 off the 1.2 branch and then simply move 
> LogFactor5 out to its own jar, that would make Log4j.jar leaner/meaner and 
> satisfy LogFactor5 users.
>
> >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.
> >
>
> Well, the easiest way to make 1.3 compatible with 1.2 is to develop 1.3 
> off the 1.2 branch.  I think that some priorities got bit mixed up in the 
> development of 1.3.  The original intention was Log4j internal logging 
> rather than using LogLog along with a more robust repository selector. 
> There were some other things, but these were biggies for me.  The problem 
> was that, in developing these new features, backward compatibility took a 
> back seat.  What are we going to do about the repository selector 
> interface?  It changed significantly!  What about those people that 
> implemented their own?  They won't be compatible with the 1.3 one.  I 
> think you will find that just about any change of even minor significance 
> is going to be result in user complaints of non-backward compatibility.
>
> I wonder if we need to re-evaluate what the Log4j-13 feature set ought to 
> be now that backward compatibility has been found, in hindsight, to be 
> priority #1.  Then we can figure out what we can add to the existing 1.2 
> branch that would be worth a 1.3 release.  Slightly incompatible changes 
> could be moved to a 1.4 or 1.5 release, but only after *lots* of 
> discussion verifying that users would be ok with the changes. 
> Uber-incompatible changes would be moved off to 2.0, which would change 
> the package namespace.  That would probably take some some to get adopted, 
> which is why agreed-upon partially incompatible 1.4 or 1.5 releases should 
> be considered before a wholesale move to change the package namespace.
>
> Jake
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
> 



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