On 17.09.2011, at 18:47, John Vasileff wrote: > > 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? >
SocketAppender is using serialization. Since I'm the author of Lilith ( http://lilith.huxhorn.de/ ) I tend to focus on stuff like that. This is also the reason for the differentiation between the Message instance and the (laziliy) formatted message string. A SocketAppender does not have any need for a formatted message. It is perfectly valid to skip the formatting entirely and simply transmit the message pattern and the message parameters (as Strings) to safe some CPU in the logged application. Directly converting parameters into Strings as soon as we know that an event really needs to be created is crucial to make sure that the logging framework is not lying as is happening, for example, in this case: http://techblog.appnexus.com/2011/webkit-chrome-safari-console-log-bug/ A lying logging framework is really, really bad... Joern. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
