On 17.09.2011, at 23:42, Ralph Goers wrote: > > 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.
Well, I could give you my protobuf but I'm not sure if it makes sense to add it to Log4J directly. It contains more (optional) fields than Log4J will provide, partially since populating those fields has a performance impact. JUL has an event id by Thread but providing them would require ThreadLocal handling of the counter, i.e. reduces performance for very little additional info. Who would really use this information? I keep those infos in Lilith so it can import/receive events lossless but I don't think that Log4J should support them. So it's probably best to keep this out of the Log4J codebase. If we add it then we'd have to coordinate future extension. If we leave it out as a third-party implementation of the SocketAppender layout then I can just change it as needed. Joern. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
