Hello Scott,
There are several reasons. First, Strings are immutable while objects
are not. Second, since everything is an object in Java, when there are
several variants of a printing method with the same name (overloaded
methods), having object as the first parameter creates too much
ambiguity in method name resolution. There is much less ambiguity in
method resolution when the message is of type java.lang.String.
Admittedly, this is less flexible than allowing java.lang.Object as
the message type. One degree of liberty is lost. There are many ways
in which a java.lang.Object can be transformed into java.lang.String
whereas there is much less liberty when transforming java.lang.String
into java.lang.String.
As Thorbjørn mentioned, in SLF4J it is still possible to pass
additional arguments of type java.lang.Object. Only the message must be
of type java.lang.String. An SLF4J implementation is free to preserve
these additional parameters as java.lang.Object.
If logger implements org.slf4j.Logger, then one can write
String name = "Scott";
logger.debug("Hello Scott");
logger.debug("Hello {}", name);
Both log statements will print as "Hello Scott". However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug("Hello", new Object[]{new Integer(37), aMap, aList});
The output message will be "Hello" but assuming the argument array is
preserved in the logging event, the logger implementation can process
the parameter array as it sees fit. In other words, adoption of the
SLF4J will not hinder support for properties. On the very contrary, it
*enables* such processing.
Scott Deboy wrote:
I'd like to understand why the Logger trace/debug etc. base methods take a string instead of an object.
I'd like to think there's usefulness in supporting something like
ObjectRenderer or ReflectionPolicy/MapPolicy+RewriteAppender - supporting only
strings makes this difficult.
Whatever we do moving forward, I'd like to see increased support for
properties. MDC and NDC are useful, but something that isn't thread specific
would be useful (one reason why property rewrite policy/rewriteappender were
created was to get around this limitation).
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
