Joern Huxhorn wrote:
I also still think that the LoggingEvent should not know about the logic behind the transformation from the Object[] arguments to the String[] arguments.
I am quite puzzled by your line of thought expressed above. Looking at d.h.lilith.data.logging package, while the LoggingEvent class does not know about message formatting, the logic is present in the Message class (in the same package) does know about message formatting logic. It seems like d.h.lilith.data.logging.LoggingEvent class delegates message formatting logic to a subcomponent but the logic is still there. (I actually like the way its done. However, I am confused about your suggestion to remove the logic taking your code as example, while that code contains the said logic.)
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: interface ILoggingEvent { Object[] getArgumentArray(); CallerData[] getCallerData(); Level getLevel(); String getLoggerName(); Marker getMarker(); Map<String, String> getMDCPropertyMap(); String getMessage(); String getThreadName(); ThrowableDataPoint[] getThrowableDataPointArray(); long getTimeStamp(); void setArgumentArray(Object[]) // other setters omitted }
I'm not very fond of the memento suggestion because it would create twice the amount of objects as the current implementation and I guess that this will have some garbage collection impact.
Absolutely. There will be an impact on the number of objects created. At present time, when a LoggingEvent is serialized, no new object is created. With the memento proposal, a new object would be created. The cost of this new object may or may not be important. We'd need to benchmark the cost. Placing serialization concerns in a new class is likely to simplify LoggingEvent which will no longer need to worry about being accessible on a remote host. So presumably, the new code will be simpler. As for your suggestion to make LoggingEvent a dumb object with only getters and setters, since several LoggingEvent fields are computed lazily, the computation logic would need to be moved somewhere else, possibly into appenders, which seems like a bad idea to me. On the host where LoggingEvent data is generated, we just can't ignore lazy computation of certain LoggingEvent fields. Did I misinterpret your idea?
I'd have absolutely no problem donating all that code back to both Logback and > SLF4J, although some work would be required to backport it to jdk < 1.5...
I appreciate the offer. You should perhaps consider filing a contributor license agreement. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch