You're wasting my time.
At 13:44 11.06.2002 +0100, you wrote: >Great so your "Problem Definition" was a trap rather than a constructive >comment. Sorry I didn't step into it. > > > > > > > Sigh. > > > > >So in the spirit of not being constructive consider: > >Problem: > >My project uses product X which depends on log4j version 1.0.4 (it uses >Category.assert). My project also uses product Y which depends on log4j >version 1.2 (it uses Category.assertLog amongst many other features). >Product X is not actively maintained. It has been replaced with product X++ >which only works using Java 1.4. X.com refuses to produce a maintenance >release of product X saying "either don't upgrade log4j or use Java 1.4". >They are very apologetic and tell us that they will take steps to ensure >that such a problem won't happen again, but unfortunately they use >Category.assert in every single java file so the testing overhead of >producing such a maintenance release is too great. The appserver we bought >doesn't work with Java 1.4 - they don't think they'll have a release ready >till Christmas so we can't upgrade to Java1.4. On the other hand Y.com just >laughs when we ask them to produce a maintenance release that works with >log4j 1.0.4. > >After a bit of head scratching we get the source for log4j 1.2 and add in >the needed Category.assert method and everything seems OK until one of our >users opens the rarely used logging window and we get a stack trace because >LoggingEvent.getThrowableInformation() used to return a String but now >returns a ThrowableInformation. We are beginning to suspect that this >problem is going to be a nightmare to resolve. > >The versions of log4j that I could find on your website are 1.0.4, 1.1.3 and >1.2. By inspecting the Javadoc I have observed that between 1.0.4 and 1.1.3 >LoggingEvent.getThrowableInformation changed return type. It was not >deprecated in release 1.0.4. Likewise from 1.1.3 to 1.2 Category.assert >changed to Category.assertLog without any deprecation warning. > >Company X tried to get in touch with the people writing log4j and try to >gain some assurances about the future binary compatibility of log4j. >Apparently log4j only breaks backwards compatibility every 2 years. Company >X thought this was a bit disingenuous given the track record and the fact >that log4js documentation says that they are planning to discard what was >once the most central class in 1 years time. > >Company X will not be using log4j going forward. We are having words with >company Y. This is a real pity because log4j was so nearly a really powerful >tool. -- 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
