Jakob,
This is in response to your message: http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=102515744931150&w=2 It is also included below for easy reference. Your proposal is one of the best motivated of its kind. My suggestion to you would be to use the Decorator pattern by wrapping the commons-logging API. I intend to use your requirements as a study case for log4j wrappers in my book. Regards, ---- Included message -------- List: jakarta-commons-user Subject: Proposal for enhancing org.apache.commons.logging.Log From: "Jakob Braeuchi" <[EMAIL PROTECTED]> Date: 2002-06-27 5:57:40 hi, i'd like to propose some enhancements to the org.apache.commons.logging.Log interface: void debug(Object aMessage, Object aParameter) void debug(Object aMessage, Object aParameter, Throwable anException); the same extension should be done for methods info, error and fatal. what's the benefit of this new methods: a.) the ojb team (http://jakarta.apache.org/ojb) needs a lot of logging where user objects are part of the logging-string. logger.debug("deleting " + obj); we had the problem that in some cases the toString() of the user object failed, which alse broke our logging. the proposed enhancements would allow as to use: logger.debug("deleting", obj); and all implementation details of the failsafe logging methods with try/catch around toString() could be hidden. b.) the toString() method of some objects may be costly and it should only be done when the loglevel mathes. i know there are methods to query the loglevel isDebugEnabled() bit imho the logging-call should be a simple one liner. c.) java.util.logging of jdk 1.4 also supports parameters. thanks jakob -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
