We also have a wrapper class around Log4J, so in a broad sense, we could accomodate changes, but I'd like to make a very important point -- the log4j customer base is likely comprised of developers using other open source products, and not all release with the same version of log4j.
Unless you can guarantee all open source users of log4j release in parallel, you will create what we call "jar wars" -- trying to get multiple products with different versions of a .jar to remotely play together. A good example is the Exolab Castor product for XML parsing, JDO, etc. They release with little concern about backward compatibility, and yet their product is embedded in many other applications. And everytime we get a new release that forces us to move ahead to a new Castor, we can guarantee a week or more of hassles, getting things to build and work again. On the other hand, the OpenJms product also from Exolab does a superb job in maintaining backward compatibility and moving forward incrementally. So I would 2nd the suggestion -- if you are going to change interfaces, PLEASE be backward compatible, even if it means the old interfaces take a slight performance hit. ... ron cain Synchron Networks -----Original Message----- From: John Fisher [mailto:[EMAIL PROTECTED]] Sent: Friday, October 26, 2001 9:27 PM To: [EMAIL PROTECTED] Subject: Abstracting away Log4j? Hi folks- I'm part of a rather large Java development effort. Some time ago, I introduced Log4J as a logging mechanism, and it has grown to be widely used across our code base. Concerns have been raised, however, that references to 3rd party software should be avoided. As it is now, every single class we have imports log4j. There has been a suggestion that we put a "wrapper" around Log4J to isolate it to one or a few classes. The fact that Log4J will be moving from Category to Logger and from Priority to Level in the next version certainly does fuel the concern, as now we are faced with updating our code base to reflect these changes (yes, I know they old classes will be staying around for a while). But, it's clear to me that Log4J is the best out there, and I'm very concerned that any "wrapper" we might impose on it might hinder it's functionality. It would seem to me that a wrapper would: - cause a second method call for every log message, causing some minor (but probably minimal) reduction in performance. - no longer allow us access to extended runtime information in the log messages, such as the class, method, line number, etc. What are the opinions on these two concerns? Of course, figuring in to all this is the java.util.logging capability of JDK1.4. I've seen a lot of concerns about it, but clearly Log4J is making an effort to pattern its class names in that direction. Unfortunately, it doesn't appear that a standard logging interface exists, ala JDBC for database interaction. That would certainly help things. So, one things I've considered is sticking with Log4J and changing our code to the new Logger and Priority, with the idea that at least we'd still be relatively close to java.util.logging capablity. Thoughts on how I should respond to these concerns? Thanks, John --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
