Ceki Gülcü wrote: > > You're wasting my time. > Actually I think that John's comments sum up the problem very clearly albeit in a slightly frustrated way and your reaction is not helpful at all. Both John and I (and others) have serious concerns about this and if you spent some of your precious time to try and look at it from out point of view we could maybe come up with a solution which would satisfy everyone.
> 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. > -- 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
