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