logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Deboy <scott.de...@gmail.com>
Subject Re: log4j2 parameterized msg with throwable
Date Sun, 18 Sep 2011 15:44:02 GMT
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 <jhuxhorn@googlemail.com>  
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>

---------------------------------------------------------------------
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