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