[logback-dev] RFC: LoggingEvent redesign

[Ralph Goers]

On Feb 24, 2009, at 7:36 AM, Joern Huxhorn wrote:

> Ceki Gulcu wrote:
>> Joern Huxhorn wrote:
>>
>>> Therefore I'd suggest to define void setArgumentArray(String[])
>>> instead of void setArgumentArray(Object[]) (see
>>> http://jira.qos.ch/browse/LBCLASSIC-45 )
>>
>> As Ralf mentioned, under certain circumstances it may be useful to
>> place objects types other than strings as parameters to logging
>> event. In my previous proposal for ILoggingEvent the
>> getArgumentArray() method returned String[]. I think this should be
>> modified to Object[] because even if only strings are serialized, we
>> should probably not impact local usage of parameters. ILoggingEvent
>> then becomes:
> I knew that somebody posted to one of the lists that he's using the
> Object[] feature in his code but I couldn't remember who it was.  
> Sorry,
> Ralph.
>
> I can absolutely see Ralphs point but I'd consider it downright
> dangerous to defer the evaluation to Strings, especially in case of
> asynchronous appenders.
>
> Take, for example, an object that is persisted using Hibernate.  
> Calling
> toString() at the wrong time could very well lead to a  
> LazyInitException.
>
> Or worse, what if an Object changes state (and string representation)
> between the logging call and the evaluation of the message? The  
> message
> would essentially contain a lie. It would seem that the call to the
> logging method was different than it was in reality.
>
> Imagining to debug a problem like this is pure horror and would mean
> "forget logging, use a debugger" all over again :(
>
> And, last but not least, transforming to String[] immediately would  
> also
> mean that any synchronization/locks would still be the way they (most
> likely;)) should be.
>
> Concerning your use case, Ralph, aren't you using an XLogger instance
> for that kind of magic? Couldn't you implement the "magic" part in the
> XLogger.
>

Yes and no. The API would be a call like logger.logEvent(EventData  
data);  EventData is really just a Map with a few extra methods. Under  
the hood the event data gets serialized to XML as the "message" but  
the EventData map is still passed as a parameter. Then when the  
Appender gets the LoggingEvent it can first check for the map being  
present. If it is it can just use it and the serialized XML just gets  
ignored. Otherwise we have to go through the expense of reconstructing  
the map from the message. If one of the out-of-the box Appenders is  
used then the map will be ignored and only the serialized map is  
recorded, but if someone wants to write a custom appender it will save  
quite a bit of overhead in not having to reconstruct the EventData map  
on every audit event.

Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-dev/attachments/20090224/705862d4/attachment.htm>