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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
