Chainsaw does a similar thing by adding event properties when the
event is received. It does this regardless of which Receiver received
the event.
On Sep 18, 2011, at 4:54 AM, Joern Huxhorn <[email protected]>
wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
