[logback-dev] RFC: LoggingEvent redesign
rgoers at apache.org
Tue Feb 24 16:59:09 CET 2009
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.
> 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.
> toString() at the wrong time could very well lead to a
> Or worse, what if an Object changes state (and string representation)
> between the logging call and the evaluation of the message? The
> 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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the logback-dev