[slf4j-dev] Release of SLF4J version 1.6.0-RC0

[Joern Huxhorn]

On 27.04.2010, at 06:38, Ralph Goers wrote:

> Adding a throwable to an event with structured data makes no sense. The throwable, or components of it, would be part of the structured data. To do what you are suggesting you might as well do:
> 
> LogEvent event = new LogEvent(Level.ERROR, msg).addParam("parm1").addThrowable(t);
> logger.log(event);
> 
> The point of the Message interface is to provide a bit more structure around the message, not encapsulate all the logging attributes such as the Marker, Level, etc into it.

Exactly.
The actual Message implementation could be as complex as necessary to accomplish the required task but it would still be required to implement the minimal lazy-init-caching-toString defined in the Message contract.

The big payoff will not show up in SLF4J but mainly in Logback where it would be possible to add explicit support for certain message implementations to custom appenders while out-of-the-box appenders would handle all Message instances similar to a String.
I'd imagine to define a small set of "standard" message implementations, guaranteeing that they are available if slf4j-api is available on the classpath. In case of SocketAppender, those standard messages could be serialized as they are while others would need to be converted into String.

Another benefit would be the ability to filter based on the actual class of the Message instance, e.g. only consume Messages of type AuditMessage or ignore all Messages of type TraceMessage (<= this is just an example but could be reasonable).

Cheers,
Joern.