well said. the Logger -> Category change is quite significant and raised some concerns of mine as well.
--- John Armstrong <[EMAIL PROTECTED]> wrote: > I fully agree with the points you make - and thank > you for clarifying the > expected lifecycle of log4j. > > Unfortunately your answer doesn't alleviate all my > concerns. In a nutshell > my problem is that using any third party software > exposes code I release to > risk and I am trying to evaluate the risk involved > in using log4j. Until > today I had thought of log4j as almost risk free > because I had (completely > stupidly) treated its API as having the same > backwards compatibility as the > standard Java APIs. I think I allowed myself to be > hoodwinked by the fact > that both sets of javadocs are written in the same > shade of blue. > > Sadly for me I work in an industry where code often > hangs around for > millennia - I think the JDBC drivers we use are as > old as JDBC itself for > instance. Using any third party code exposes my code > to risk. The question I > am asking myself is "Would I be irresponsible if I > released code into such > an environment when I knew that the ongoing > maintainability of that code is > subject to the risk of unexpected API changes?". I > think that the answer to > this question is probably yes - and I know that I am > not the only log4j user > who has inadvertently opened themselves up to such a > risk. > > The solution to the problem is pretty obvious - > namely that some subset of > log4j should be specially singled out as the core > API with strong guarantees > of backwards compatibility. The crux of the issue is > whether or not the > developers of log4j are willing to shoulder the > burden of designing and > maintaining such a core API. > > To get to the point I would really like the > developers of log4j to say "We > are willing to maintain x subset of our API forever > with 100% backward > compatibility". I understand completely why you > would be reluctant to make > such a commitment but I would like to try and tempt > you: > > 1. For most users of log4j the only methods used are > the logging methods of > Category and Category.getInstance or the equivalent > methods of Logger (this > is based on supposition not research). So a core API > that would satisfy such > users would be tiny. > 2. Sun has written a logging API for Java. So long > as your core API is less > functional than this you can benefit from the work > they have done and steal > their guarantees. > 3. A key selling point of log4j over the new logging > API for Java is the > compatibility of log4j with different versions of > Java - thus the users of > log4j are very likely the kind of people who have > cause to worry about > interoperability. > 4. Another key selling point of log4j is that it > could be the de facto > standard for logging in Java - in particular third > party libraries are > likely to use it allowing the logging to be unified > in the application. Once > again this is exactly the situation where concerns > about interoperability > are paramount. > > I hope you're tempted - or failing that I hope you > can convince me that it > wouldn't be irresponsible to use log4j in a JDBC > driver with a 10 year life > expectancy. > > > > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] > Sent: 06 June 2002 12:34 > To: Log4J Developers List > Subject: Re: Binary compatibility between versions > of log4j > > > John, > > This is a deep and tough question. The problem of > binary compatibility is > intrinsic to the nature of software. On one side, > unlike other engineering > endeavors, software can be easily modified and > enhanced. On the other side, > this make it very easy to break compatibility with > previous versions of the > software. > > In widely used infrastructure libraries like log4j, > the question of binary > compatibility is singularly acute. It is not > uncommon to see an application > composed of several libraries each of which depends > on log4j for its > logging. If any two of these libraries depend on > incompatible versions of > log4j, the application may not run smoothly. In a > library as large and wide > as log4j, it is exceedingly difficult to preserve > 100% backward > compatibility between the oldest and newest > versions. Nevertheless, changes > that break binary compatibility are few and limited > in scope such that the > number of affected users is minimal. One notable > exception is the > deprecation of the Category class. If you read > between the lines, the > javadocs promise that the Category class will be > kept around until mid-2003. > This does not necessarily mean that it will be > removed after that date... > > Our current policy forbids the removal of a > deprecated field, method or > class before two complete major release cycles > elapse. In other words, a > method deprecated in log4j 1.2 cannot be removed > until version 1.5 is > released, leaving developers over two years to adapt > to changes in log4j. > This policy applies to log4j version 1.2 and later. > In earlier versions, the > completion of only *one* release cycle was required > for the removal of a > deprecated method. > > I hope this answers the question and alleviates your > concerns. > > At 11:04 06.06.2002 +0100, John Armstrong wrote: > >What guarantees are there (if any) for binary > compatibility between > >different versions of log4j? > > > >We have recently had to upgrade from version 1.0.4 > of log4j to version > >1.1.3. I was surprised to notice that there was not > complete binary > >compatibility between these releases though > fortunately it was easy to > >change our code. However, the following situation > could easily have > >arisen: > > > >Suppose library1 uses log4j 1.1.3 with its > "Category.assert" method and > >library2 uses "Category.assertLog" from log4j 1.2 > the only solution is > >to ask one of the library vendors to change their > code. (Or to compile > >your own hacked together log4j "version" with a > both methods). > > > >My concern about this issue was increased when I > saw in the javadocs > >that Category is now deprecated and is scheduled > for deletion next > >year. If and when that happens won't a lot of > libraries require > >conflicting versions of log4j making it difficult > to use log4j with > >code supplied from multiple vendors? > > > >Thanks for any light you can shed on this, > > > >John > > -- > Ceki > > SUICIDE BOMBING - A CRIME AGAINST HUMANITY > Sign the petition: > http://www.petitiononline.com/1234567b > I am signatory number 22106. What is your number? > > > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
