[logback-dev] RFC: LoggingEvent redesign

[Joern Huxhorn]

Hi Ceki, Thorbjoern and Maarten,

I'd like to encourage all of you to take a look at my LoggingEvent  
implementation at http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data 
  , more specific the classes in http://apps.sourceforge.net/trac/lilith/browser/trunk/lilith-data/logging/src/main/java/de/huxhorn/lilith/data/logging

The LoggingEvent is just a dumb data container with the only logic  
being a (lazy) call to MessageFormatter if the formatted message is  
actually needed.

Beside that, all the classes are simply Java Beans with both getters  
and setters for everything. They also have a default c'tor.

This means they can be persisted using java.beans.XMLEncoder/ 
XMLDecoder which would probably be the best candidates to support  
future updates because they handle such a situation gracefully.

I've done some benchmarks which you can check out at http://apps.sourceforge.net/trac/lilith/ticket/28

XML encoding *is* significantly slower, especially because gzipping  
isn't just an option but a must if you take a look at the increase of  
size in case of XML.

Concerning immutability, I seriously fail to see any advantage of  
immutable data objects because the immutability can be circumvented  
anyway.

Because of that it should be sufficient to define the hierarchy like  
this:

interface ImmutableLoggingEvent {
   // only getters
}

interface MutableLoggingEvent extends ImmutableLoggingEvent {
   // only setters
}

class LoggingEvent implements MutableLoggingEvent {
}

and simply using the LoggingEvent as an ImmutableLoggingEvent as  
needed to document that certain classes, like appenders, aren't  
supposed to change the event.

Granted, it would obviously still be possible to cast it to  
MutableLoggingEvent but it's also possible, on the other hand, to  
change private variables using reflection, so immutability is only a  
contract/illusion, anyway.

I also still think that the LoggingEvent should not know about the  
logic behind the transformation from the Object[] arguments to the  
String[] arguments.

Therefore I'd suggest to define void setArgumentArray(String[])  
instead of void setArgumentArray(Object[]) (see http://jira.qos.ch/browse/LBCLASSIC-45 
  )

My LoggingEvent is using a ThrowableInfo similar to the class I  
suggested in http://jira.qos.ch/browse/LBCLASSIC-46
It's keeping the throwable hierarchy intact because a ThrowableInfo  
can have another ThrowableInfo as it's cause and so on...

On a side note, the MessageFormatter contained in the same package  
implements my suggestions from the following slf4j "bugs":
http://bugzilla.slf4j.org/show_bug.cgi?id=31
http://bugzilla.slf4j.org/show_bug.cgi?id=70
http://bugzilla.slf4j.org/show_bug.cgi?id=112
(there's just one usability glitch left which I'll fix in the near  
future but I'll leave it up to you to spot it ;))

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...

Oh, I almost forgot: My LoggingEvent does also contain support for an  
enhanced version of the NDC - but that functionality could simply be  
removed if undesired.

What do all of you think?

Joern.


On 23.02.2009, at 18:58, Ceki Gulcu wrote:

>
> Thorbjoern Ravn Andersen wrote:
>> Ceki Gulcu skrev:
>>> Hello all,
>>>
>>> I would like to split/redesign the LoggingEvent object as follows:
>> Hi.
>> Could you elaborate on what you want to achieve?  Makes it easier  
>> to evaluate your suggestion.
>
> One important goal is to better support interoperability between  
> logback versions.  For example, in a client/server situation, when a  
> client is using a different version of logback than the server. Here  
> the client is the application generating LoggingEvent instances and  
> the server is the application receiving serialized LoggingEvent  
> instances via the network.
>
> A second goal is to simplify the code in LoggingEvent. If  
> LoggingEvent instances do not have to worry about serialization,  
> then LoggingEvent can be simplified. LoggingEventMemento needs to  
> worry about serialization, replacing LoggingEvent in client/server  
> communication.
>
> Another goal of this RFC is to identify uses of LoggingEvent so that  
> logback can cater for those use cases, possibly via new object types.
>
> It is not clear how LoggingEventMemento would actually ensure  
> version compatibility, especially if LoggingEventMemento fields  
> change in time. However, as LoggingEventMemento is only a data  
> carrying tpye, it is likely to be much smaller in (code) size.
>
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework  
> for Java.
> http://logback.qos.ch
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev