On Sep 17, 2011, at 8:53 AM, Joern Huxhorn wrote:

> Adding getThrowable() would also reintroduce the issue that such a Message 
> could not be serialized securely since deserialization would require the 
> exceptions class on the classpath. In my ParameterizedMessage over at 
> https://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/n/messages/ParameterizedMessage.java
>  the Throwable is transient so it is deliberately lost while serializing, 
> i.e. it must be taken care of by the framework immediately after the message 
> is created.
> 
> It is only contained in ParameterizedMessage at all simply because a method 
> can only return a single value. And the create-method is also responsible for 
> resolving the Throwable at the last position of arguments if it is not used 
> up by a corresponding {}.
> 
> Yes, it would be "cleaner" to split that into a parseresult object that 
> contains both the message and an additional, optional Throwable. I just 
> didn't implement it that way to reduce the amount of garbage (that 
> parseresult object would get garbage-collected immediately after evaluation).
> 
> So adding Throwable to ParameterizedMessage was just a performance 
> optimization.
> 
> The serialization issue is btw also the reason for *not* having Object[] 
> getParameters() but String[] getParameters() instead. The String 
> representation is the serialization-safe version of the parameters.
> 
> But all of this is, in my books, an implementation detail of the Message 
> implementation with getFormattedMessage() being the only "public" API of 
> Message.
> 
> Joern.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

Interesting point on serialization.  When would you see serialization 
happening?  Is this primarily for appenders?


John
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to