On Thursday 06 June 2002 22:18, Anders Kristensen wrote: > Well, you always have the option of not upgrading to newer versions of > log4j. It sounds like that's the strategy you've chosen for JDBC > drivers. Then what you need is a assurance that the old version you're > using will continue to be maintained and have bugs fixed etc. That's a > very different thing and one for which it will probably be easier to get > a "guarantee".
If you are a "component" provider, this may also impose problems, since your customer may use your component (C) AS WELL AS log4j (L). If customer don't upgrade C, with the embedded L, and upgrade its own L, OR that C expects an external L (which is now upgraded, binary incompatible), you have a problem. My advice; Wrap your logging into your own classes, and have a SPI serving "switch" so that if you determine that Log4J is available and compatible, use it, otherwise check for Java Logging API (JDK 1.4 will be historical when Log4J breaks binary compatibility), and worst case, fall back to System.out. Niclas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
