[slf4j-dev] Structured data "was Plan for SLF4J 2.0"

[Joern Huxhorn]

On 10.03.2010, at 09:46, Ceki Gülcü wrote:

>
>>> The end result is very similar to asking your  
>>> StructuredDataMessage in
>>> the org.slf4j.message package for its formatted message, except that
>>> the question is asked by a RFC5424Encoder. A different encoder would
>>> ask a different question.
>
> > This is not similar at all. The layout/encoder/whatever calls
> > getFormattedMessage and gets an appropriate response. Since  
> everything
> > is a Message the method is always there.
>
> How is this different than toString()? Everything is an object and the
> toString() method is always there.

Well, the idea was the following:

I didn't want to allow just any type of Object - which would be  
possible if we'd simply use toString().
I wanted to emphasize the use of Messages of certain types instead of  
simply dumping just any Object into the Logger.

Message.getFormattedMessage() is supposed to return a lazily  
initialized and cached String representation of the message. (I'm not  
sure if this has been documented yet. Chances are good that it isn't)

toString(), on the other hand, can still be used for debugging output  
of a Message. toString() is generated code (by Eclipse or IDEA) most  
of the time. Even if that isn't the case, I dare say that it's caching  
it's result  very seldom. I'm only talking about the typical  
implementation here.

Since multiple appenders might use the formatted message of the same  
event, caching might make a rather big difference.

It's just a semantic difference and an attempt to push the user in a  
certain direction (i.e. "Take a look at Messages!").
This semantic difference should be documented in the Message  
interface, obviously.

Cheers,
Joern.