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