[logback-dev] RFC: LoggingEvent redesign

[Ceki Gulcu]

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