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.
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
