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