[slf4j-dev] [Bug 19] nlog4j is incompatible to log4j
bugzilla-daemon at gil.qos.ch
bugzilla-daemon at gil.qos.ch
Wed Feb 8 20:55:01 CET 2006
http://bugzilla.slf4j.org/show_bug.cgi?id=19
listid at qos.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From listid at qos.ch 2006-02-08 20:55 -------
Indeed, com.mysql.jdbc.log.Log4JLogger confirms your
report. Unfortunately, I don't think it is possible to have two
printing methods, one with the signature (Object, Throwable) and the
other with signature (String, Object). For example, if the following
two methods existed in o.a.l.Category
debug(Object msg, Throwable t);
debug(String msg, Object arg);
then, the following common statement
logger.debug("hello", new Exception());
would cause a compiler error, affecting thousands if not millions
lines of code. As such, I am regretfully marking this bug as WONTFIX.
Would be possible to change the com.mysql.jdbc.log interface so that
they take strings instead of objects? You could perhaps convince the
MySQL folks of the benefits of such a change using an efficiency
argument.
If the com.mysql.jdbc.log interface ressembled more that of
org.slf4j.Logger, they could have more efficient support for
ProfilerEvent objects.
For example, they could write:
import org.slf4j.impl.MessageFormatter;
import om.mysql.jdbc.log.LogUtils;
public class XYZImpl implements com.mysql.jdbc.log {
...
public void debug(String formatMsg, Object arg) {
if(isDebugEnabled() {
String m = MessageFormatter.format(formatMsg, LogUtils.
expandProfilerEvent(arg));
this.logger.debug(m);
}
}
...
}
If the SLF4J dependency is unacceptable, they could copy
MessageFormatter code into somewhere under com.mysql.jdbc.*.
What do you say?
--
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the slf4j-dev
mailing list