On Sep 17, 2011, at 1:43 PM, Joern Huxhorn wrote: > > On 17.09.2011, at 21:26, Ralph Goers wrote: > >> >> 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: >>>> >>>> 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. > > Your SocketAppender is obviously much improved compared to the Logback one. > Having the actual serialization mechanism pluggable is a very good idea. > Nevertheless, I assume that simple serialization would be the "reference > implementation". I'd, of course, hook in my protobuf implementation...
If you provide a ProtobufLayout I'd happily include it - although I'd make the protobuf artifacts optional dependencies as I did for Flume. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
