Joern, Accepting parameters of type Object instead of String opens the door for nasty bugs as you point out. At the same time, it also constitutes an important extension point for logback within the limits imposed by the SLF4J API. I think that the org.slf4j.Logger class should contain a waring (in red) about the arguments being evaluated asynchronously. At present time, we serialize stringified version of the arguments. However, we could imagine that certain types, such as maps and collections, or other well-defined types be serialized as is (without transformation into String). Thus, not only would be it possible to take advantage of specific object types locally but also remotely. Regarding the lazy evaluation of LoggingEvent fields such as caller data and others, the current approach is highly dynamic. For example, if an appender named A requires caller data but is not on the processing path of the current logging event, then caller data will not be evaluated. Setting caller data evaluation as an option at the level of the logger context is not as flexible. Moreover, if any single appender performs the computation of a given field in logging event, that field become available for all subsequent appenders. I tend to think that the way logging event does lazy evaluation of fields works quite well. For the contributor license agreement, please see: http://logback.qos.ch/license.html and http://logback.qos.ch/cla.txt Cheers, Joern Huxhorn wrote:
I can absolutely see Ralphs point but I'd consider it downright dangerous to defer the evaluation to Strings, especially in case of asynchronous appenders.
Take, for example, an object that is persisted using Hibernate. Calling toString() at the wrong time could very well lead to a LazyInitException.
Or worse, what if an Object changes state (and string representation) between the logging call and the evaluation of the message? The message would essentially contain a lie. It would seem that the call to the logging method was different than it was in reality.
Imagining to debug a problem like this is pure horror and would mean "forget logging, use a debugger" all over again :(
And, last but not least, transforming to String[] immediately would also mean that any synchronization/locks would still be the way they (most likely;)) should be.
Concerning your use case, Ralph, aren't you using an XLogger instance for that kind of magic? Couldn't you implement the "magic" part in the XLogger.
As for your suggestion to make LoggingEvent a dumb object with only getters and setters, since several LoggingEvent fields are computed lazily, the computation logic would need to be moved somewhere else, possibly into appenders, which seems like a bad idea to me.
This logic would reside in the Logger, actually. It would, in my scenario, transform the Object[] to String[], resolve the ThreadName and extract CallerData while synchronously creating the actual LoggingEvent.
ThreadName and CallerData evaluation would be activated/deactivated globally instead of in an actual appender. That way, there would be no performance impact if they are not requested.
Evaluating the above mentioned stuff lazily would produce wrong or inaccurate results if executed from a different thread, am I right?
On the host where LoggingEvent data is generated, we just can't ignore lazy computation of certain LoggingEvent fields. Did I misinterpret your idea?
Only the lazy bit. I'd eagerly (synchronously) evaluate everything that is required in Logger but stuff like the creation of the formatted message is done lazily.
I'd have absolutely no problem donating all that code back to both Logback and > SLF4J, although some work would be required to backport it to jdk < 1.5...
I appreciate the offer. You should perhaps consider filing a contributor license agreement. That wouldn't be a problem, I guess, if I'm not required to sell my soul or something ;) Where can I find it? Just let me know when you think it's necessary.
Joern.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch