On Sep 17, 2011, at 11:40 AM, Joern Huxhorn wrote: > > 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.
Actually, in Log4j 2.0 SocketAppender uses a Layout. The default Layout is SerializedLayout. If you want to use a LillithLayout you would be free to do so. > > 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. I disagree. The SocketAppender should be able to interact with something that accepts Thrift, Avro, Hession or other serialization protocols or even the RFC 5424 format. However, in cases where the event is serialized into a format where the LogEvent will be recreated on the other side of the socket connection, I agree that formatting the message on the sender's side is not required. > > 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... Agreed. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
