logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joern Huxhorn <jhuxh...@googlemail.com>
Subject Re: log4j2 parameterized msg with throwable
Date Sun, 18 Sep 2011 11:54:19 GMT

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message