At 09:33 PM 1/12/2006, Scott Deboy wrote:
General SLF4j concern:
I may be in the minority (I'm sure I am), but slf4j's change to require
logger.debug(string) instead of object may have a performance rationale
but it has the effect of preventing filters from being able to perform any
analysis based on what was passed into the logging method.
The rationale for the logger.xxx(String) instead of logger.xxx(Object) has
nothing to do with performance but with clarity. Given that everything is
an Object in java, it is not always possible to properly distinguish the
following method calls:
debug("hello {}", "world");
debug(MyMarkers.BLUE, "Hello world");
debug("hello world", new Exception("just testing"));
One quickly runs into combinations that the compiler finds ambiguous and
refuses to compile. I tried keeping the first Object parameter and had the
compiler shouting. IMHO, it's just not possible.
See
http://logging.apache.org/log4j/docs/api-unstable/org/apache/log4j/filter/ReflectionFilter.html
To work around this issue, we could add additional methods to logger that
took an interface as well as a String, and users would pass in instances
of the interface (which provided a way to get the underlying object and
delegated tostring to the underlying object if the filter wasn't being
used). Maybe a Wrapper interface that provided a getObject method.
If you really need to pass the object as is, you can always do it as follows:
debug("{}", myObject);
This assumes that the implementation does not immediately convert
parameterized messages into string but keeps myObject available for further
processing. I am doing exactly this in LOGBack, my experimental logging
system. There is no reason why log4j couldn't do the same.
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
