You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Rafael Alvarez <so...@yahoo.com> on 2002/03/19 15:44:40 UTC
Re: Binary compatibility between versions of log4j
This topic is getting hotter by the minute!
I agree that binary compatibility between versions is something
important, as it relieves the end user (us developers) from the
tedious task of rewriting our app to conform to the latest spec.
BUT (and this is a big BUT here) you'll never know what will happen in
the future. The JUnit project suffered a big impact when the assert
keyword was introduced in jdk1.4 (the same case as log4j
Category.assert() renamed to Category.assertLog()), as they had to
change the assert() to assertTrue in one of his CORE classes to make
it compatible with 1.4 (and that forced the rewriting of thousands of
test all over the world from those who wanted to use the latest JUnit).
Is the JUnit team responsible? I guess not.
<RANTING STARTING - YOU CAN SKIP IT IF YOU WANT>
Some may say that testcases written for Junit are easily modifiable
with a text-replacing tools, and that's true. I'm just making a point.
Another example is the servlet API. From 2.1 to 2.2 some methods got
deprecated (HttpSession getValue() and setValue() came to mind). And
some method in the Thread got deprecated, etc,etc.
My point it: Perhaps some things will get deprecated, and you have to
be prepared to it. Java is not always binary compatible itself, so
stop bombing log4j
</RANTING>
What we can ask for is an stable subset of the core API (Like
Logger and Level related stuff). Even more, a set of adapters can be
created to solve compatibility issues and to help . That should solve
most of the problems.
As for using products that rely on different versions of log4j, well,
you have the source code of all the milestone versions of log4j. Try
to reconciliate them and recompile. Sadly that's a problem that plage
all the software world.
m2c,
Rafael mailto:soronthar@yahoo.com
P.S: If someone feels offended by this post, I offer my apologies.
Sometimes I'm to blunt expressing my opinions.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Niclas Hedhman <ni...@ewarna.com>.
Great!
I can't argue on problems with versions of log4j, I only use 1.2, and doesn't
need to integrate with components delivered with or depending on earlier
versions. I will survive a fair amount of changes, I am not unhappy.
Your assertion here is very powerful, and indeed showing strengths and
commitments from the log4j people.
So, the statement that Category and Priority may give way somewhere down the
line, is perhaps a sore point to sensitive users. And maybe such statement
shouldn't exist, and maybe the classes be considered part of the official
API. Maybe the methods should just be remapped to Logger methods, to ease
maintenance.
I still believe a an official compatibility statement are in order. It
includes a definition of the API and a separate defintion of the SPI, and
possible a third definition of the Configuration. I bet everyone would back
such statement, would clarifiy the "unbreakable" parts, and what is "features
of your own risk" and so on.
On behalf the programming community at large, thanks for a GREAT PRODUCT, that
the "wary" parties here no doubt also think.
Niclas
On Wednesday 12 June 2002 17:49, Ceki Gülcü wrote:
> Someone recently claimed on a mailing list, on general@jakarta if I
> recall, that log4j interfaces were changing by the day. This is so
> patently untrue that I chose not to respond. Given the substantial
> number of log4j users, if we whimsically changed interfaces, the
> resulting uproar would be deafening.
>
> Saying that log4j developers take backward compatibility seriously is
> an understatement. We can't afford not to. We are being watched not
> only by our users but by automated tools as well. Jakarta-gump (See
> http://jakarta.apache.org/gump/) checks and cross checks that
> different projects in and outside jakarta do not break dependents.
> For the results of the latest check see:
>
> http://jakarta.apache.org/builds/gump/latest/
>
> (Log4j is the 8th listed project just after jakarta-ant.)
>
> Over one hundred (100) projects are thus cross checked every day. It
> is also fair to say that a few of those 100+ projects depend on log4j.
> In the past when log4j broke backward compatibility, gump quickly
> detected and reported the problem.
>
> Gump is one of our lines of defense, it is not the only the one. For
> example, log4j 1.1.x and 1.2 are compatible after serialization. (Gump
> does not check for this.) It is possible for a SocketServer running
> log4j 1.1 to receive events from a client running log4j 1.2 and
> conversely 1.2 servers to receive events from 1.1 clients even tough
> the LoggingEvent class changed between log4j 1.1 and 1.2. This
> compatibility did not happen by itself, it demanded work. Log4j 1.3
> is likely to break serialization compatibility for performance
> reasons. By implementing the java.io.Externilizable interface instead
> of java.io.Serializable, on the wire transmission of LoggingEvents can
> be improved by a factor of 4, i.e. 400%. Although log4j 1.3 is slated
> to be 100% backward compatible with 1.2, it is unlikely to be
> serialization compatible. In other words, a client class compiled with
> log4j 1.2 will run perfectly with log4j-1.3.jar but a client using
> log4j-1.2.jar will not be able to talk to a 1.3 server.
>
> When log4j 1.3 is released some people will vocally declare that the
> heartless log4j developers deliberately broke backward compatibility
> without regard to user needs. It is a free Internet. Saying that
> log4j interfaces are not stable is grossly inaccurate. Very few users
> have complained about 1.1 / 1.2 changes. Existing log4j users who had
> trouble migrating to 1.2, are kindly invited to tell their horror
> stories. Success stories are equally welcome.
>
> At 12:14 12.06.2002 +0800, you wrote:
> >On Tuesday 19 March 2002 22:44, Rafael Alvarez wrote:
> > > Some may say that testcases written for Junit are easily modifiable
> > > with a text-replacing tools, and that's true. I'm just making a point.
> >
> >I can make another example;
> >JDK 1.4 introduced Throwable.getStackTrace(), which broke my binary
> >compatibility with 1.4 without my participation. I had that method in all
> > my exceptions that were part of a RMI call, > 50 classes all added up.
> >
> >The lower you get in the hierarchy (JDK at the bottom, log4j immediately
> > on top of that and the project at the very top), the more impact changes
> > has on other people. JDK is getting to the point where new methods can no
> > longer be added to non-final classes, as has otherwise been declared as
> > Ok.
> >
> > > My point it: Perhaps some things will get deprecated, and you have to
> > > be prepared to it. Java is not always binary compatible itself, so
> > > stop bombing log4j
> > > </RANTING>
> >
> >Ceki, I can undertstand that you are "irritated" over this issue, but I
> > can also understand everyone's concern, as we are dealing with a VERY
> > fundamental service here.
> >I would like to suggest that one of the following approaches are taken;
> >
> >1. A declaration that if my code uses classes A, B and C directly, and
> >doesn't
> >subclass anything, compatibility will not be broken by the Log4J
> > developers.
> >
> >2. A factory for obtaining the Logger, which is an interface only, a
> >method to
> >initialize the subsystem that doesn't reference the configurator classes
> >directly. And if I stick to these, I am guaranteed a binary functionality
> > for decades.
> >
> >3. Become a JDK logging framework replacement.
> >
> >Mistakes in the past doesn't have to be repeated, nor is the Log4J obliged
> > to un-do the binary breaks of the past. But expect a flight from Log4J if
> > the issue is ignored.
> >
> >Niclas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Ceki Gülcü <ce...@qos.ch>.
Someone recently claimed on a mailing list, on general@jakarta if I
recall, that log4j interfaces were changing by the day. This is so
patently untrue that I chose not to respond. Given the substantial
number of log4j users, if we whimsically changed interfaces, the
resulting uproar would be deafening.
Saying that log4j developers take backward compatibility seriously is
an understatement. We can't afford not to. We are being watched not
only by our users but by automated tools as well. Jakarta-gump (See
http://jakarta.apache.org/gump/) checks and cross checks that
different projects in and outside jakarta do not break dependents.
For the results of the latest check see:
http://jakarta.apache.org/builds/gump/latest/
(Log4j is the 8th listed project just after jakarta-ant.)
Over one hundred (100) projects are thus cross checked every day. It
is also fair to say that a few of those 100+ projects depend on log4j.
In the past when log4j broke backward compatibility, gump quickly
detected and reported the problem.
Gump is one of our lines of defense, it is not the only the one. For
example, log4j 1.1.x and 1.2 are compatible after serialization. (Gump
does not check for this.) It is possible for a SocketServer running
log4j 1.1 to receive events from a client running log4j 1.2 and
conversely 1.2 servers to receive events from 1.1 clients even tough
the LoggingEvent class changed between log4j 1.1 and 1.2. This
compatibility did not happen by itself, it demanded work. Log4j 1.3
is likely to break serialization compatibility for performance
reasons. By implementing the java.io.Externilizable interface instead
of java.io.Serializable, on the wire transmission of LoggingEvents can
be improved by a factor of 4, i.e. 400%. Although log4j 1.3 is slated
to be 100% backward compatible with 1.2, it is unlikely to be
serialization compatible. In other words, a client class compiled with
log4j 1.2 will run perfectly with log4j-1.3.jar but a client using
log4j-1.2.jar will not be able to talk to a 1.3 server.
When log4j 1.3 is released some people will vocally declare that the
heartless log4j developers deliberately broke backward compatibility
without regard to user needs. It is a free Internet. Saying that
log4j interfaces are not stable is grossly inaccurate. Very few users
have complained about 1.1 / 1.2 changes. Existing log4j users who had
trouble migrating to 1.2, are kindly invited to tell their horror
stories. Success stories are equally welcome.
At 12:14 12.06.2002 +0800, you wrote:
>On Tuesday 19 March 2002 22:44, Rafael Alvarez wrote:
> > Some may say that testcases written for Junit are easily modifiable
> > with a text-replacing tools, and that's true. I'm just making a point.
>
>I can make another example;
>JDK 1.4 introduced Throwable.getStackTrace(), which broke my binary
>compatibility with 1.4 without my participation. I had that method in all my
>exceptions that were part of a RMI call, > 50 classes all added up.
>
>The lower you get in the hierarchy (JDK at the bottom, log4j immediately on
>top of that and the project at the very top), the more impact changes has on
>other people. JDK is getting to the point where new methods can no longer be
>added to non-final classes, as has otherwise been declared as Ok.
>
> > My point it: Perhaps some things will get deprecated, and you have to
> > be prepared to it. Java is not always binary compatible itself, so
> > stop bombing log4j
> > </RANTING>
>
>Ceki, I can undertstand that you are "irritated" over this issue, but I can
>also understand everyone's concern, as we are dealing with a VERY fundamental
>service here.
>I would like to suggest that one of the following approaches are taken;
>
>1. A declaration that if my code uses classes A, B and C directly, and
>doesn't
>subclass anything, compatibility will not be broken by the Log4J developers.
>
>2. A factory for obtaining the Logger, which is an interface only, a
>method to
>initialize the subsystem that doesn't reference the configurator classes
>directly. And if I stick to these, I am guaranteed a binary functionality for
>decades.
>
>3. Become a JDK logging framework replacement.
>
>Mistakes in the past doesn't have to be repeated, nor is the Log4J obliged to
>un-do the binary breaks of the past. But expect a flight from Log4J if the
>issue is ignored.
>
>Niclas
--
Ceki
SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Binary compatibility between versions of log4j
Posted by Rafael Alvarez <so...@yahoo.com>.
Paul Duffin wrote:
RA>> ... The JUnit project suffered a big impact when the assert
RA>> keyword was introduced in jdk1.4 (the same case as log4j
PD> Thanks for explaining that, that is obviously a problem with the
PD> java compilers ...
PD> However, there is an option to the JDK 1.4 compiler which allows it
PD> to use the old 1.3 syntax. Until such time as JUnit, or Log4j wanted
PD> to use the new syntax the old methods could have been kept and
PD> deprecated.
If you use that option, you're forcing all the jdk1.4 users to use it
too for they code to compile. Not that I'm saying it's a bad thing,
just pointing out one of the consequences.
PD>Once you have the adapters sorted out it would be very easy to write
PD>versions of them for the different versions of log4j.
So, I think that we should focus on defining a way to implement
adapters easily. I can go further and propose the published api to be
an adapter to the current version.
--
Best regards,
Rafael mailto:soronthar@yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Paul Duffin <pd...@volantis.com>.
Rafael Alvarez wrote:
>
> This topic is getting hotter by the minute!
>
> I agree that binary compatibility between versions is something
> important, as it relieves the end user (us developers) from the
> tedious task of rewriting our app to conform to the latest spec.
>
> BUT (and this is a big BUT here) you'll never know what will happen in
> the future. The JUnit project suffered a big impact when the assert
> keyword was introduced in jdk1.4 (the same case as log4j
> Category.assert() renamed to Category.assertLog()), as they had to
> change the assert() to assertTrue in one of his CORE classes to make
> it compatible with 1.4 (and that forced the rewriting of thousands of
> test all over the world from those who wanted to use the latest JUnit).
> Is the JUnit team responsible? I guess not.
>
Thanks for explaining that, that is obviously a problem with the
java compilers and not Junit, or log4j. It is possible for compilers
to allow reserved words to be used as functions and variables when
they are found in the 'correct' place which is something that Rexx
(or one of its derivatives) does.
However, there is an option to the JDK 1.4 compiler which allows it
to use the old 1.3 syntax. Until such time as JUnit, or Log4j wanted
to use the new syntax the old methods could have been kept and
deprecated.
> <RANTING STARTING - YOU CAN SKIP IT IF YOU WANT>
>
> Some may say that testcases written for Junit are easily modifiable
> with a text-replacing tools, and that's true. I'm just making a point.
>
> Another example is the servlet API. From 2.1 to 2.2 some methods got
> deprecated (HttpSession getValue() and setValue() came to mind). And
> some method in the Thread got deprecated, etc,etc.
>
> My point it: Perhaps some things will get deprecated, and you have to
> be prepared to it. Java is not always binary compatible itself, so
> stop bombing log4j
> </RANTING>
>
Deprecating a method is different to removing it. It merely acts as
a warning that you shouldn't be using it. I do not know whether
any deprecated method ever been removed from Java.
> What we can ask for is an stable subset of the core API (Like
> Logger and Level related stuff). Even more, a set of adapters can be
> created to solve compatibility issues and to help . That should solve
> most of the problems.
>
That is all that we are asking for.
> As for using products that rely on different versions of log4j, well,
> you have the source code of all the milestone versions of log4j. Try
> to reconciliate them and recompile. Sadly that's a problem that plage
> all the software world.
>
Once you have the adapters sorted out it would be very easy to write
versions of them for the different versions of log4j.
--
This message may contain confidential information and will be protected
by copyright. If this email isn't for you then we'd be grateful if you
could notify Volantis by return and delete it. You should not copy,
disclose or distribute any of its contents.
Any reply may be read by the recipient to whom you send it and others
within Volantis Systems Ltd.
Although we aim to use efficient virus checking procedures we accept no
liability for viruses and recipients should use their own virus checking
procedures.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Ceki Gülcü <ce...@qos.ch>.
At 10:34 12.06.2002 +0200, Giuseppe Madonna wrote:
>Yes, the classic and painless way. Some days ago, I was arguing about that
>approach in "Differences in XMLConfiguration beetween ver. 1.1 and 1.2"
>mail.
Was your XML config file written for 1.1 not readable in log4j 1.2?
Did log4j break backward compatibility in your opinion?
--
Ceki
SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Giuseppe Madonna <ma...@ised.it>.
----- Original Message -----
From: "Niclas Hedhman" <ni...@ewarna.com>
To: "Log4J Developers List" <lo...@jakarta.apache.org>
Sent: Wednesday, June 12, 2002 6:14 AM
Subject: Re: Binary compatibility between versions of log4j
> Ceki, I can undertstand that you are "irritated" over this issue, but I
can
> also understand everyone's concern, as we are dealing with a VERY
fundamental
> service here.
> I would like to suggest that one of the following approaches are taken;
>
[...]
> 2. A factory for obtaining the Logger, which is an interface only, a
method to
> initialize the subsystem that doesn't reference the configurator classes
> directly. And if I stick to these, I am guaranteed a binary functionality
for
> decades.
[...]
Yes, the classic and painless way. Some days ago, I was arguing about that
approach in "Differences in XMLConfiguration beetween ver. 1.1 and 1.2"
mail.
Best Regards,
Giuseppe.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Binary compatibility between versions of log4j
Posted by Niclas Hedhman <ni...@ewarna.com>.
On Tuesday 19 March 2002 22:44, Rafael Alvarez wrote:
> Some may say that testcases written for Junit are easily modifiable
> with a text-replacing tools, and that's true. I'm just making a point.
I can make another example;
JDK 1.4 introduced Throwable.getStackTrace(), which broke my binary
compatibility with 1.4 without my participation. I had that method in all my
exceptions that were part of a RMI call, > 50 classes all added up.
The lower you get in the hierarchy (JDK at the bottom, log4j immediately on
top of that and the project at the very top), the more impact changes has on
other people. JDK is getting to the point where new methods can no longer be
added to non-final classes, as has otherwise been declared as Ok.
> My point it: Perhaps some things will get deprecated, and you have to
> be prepared to it. Java is not always binary compatible itself, so
> stop bombing log4j
> </RANTING>
Ceki, I can undertstand that you are "irritated" over this issue, but I can
also understand everyone's concern, as we are dealing with a VERY fundamental
service here.
I would like to suggest that one of the following approaches are taken;
1. A declaration that if my code uses classes A, B and C directly, and doesn't
subclass anything, compatibility will not be broken by the Log4J developers.
2. A factory for obtaining the Logger, which is an interface only, a method to
initialize the subsystem that doesn't reference the configurator classes
directly. And if I stick to these, I am guaranteed a binary functionality for
decades.
3. Become a JDK logging framework replacement.
Mistakes in the past doesn't have to be repeated, nor is the Log4J obliged to
un-do the binary breaks of the past. But expect a flight from Log4J if the
issue is ignored.
Niclas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>