[logback-dev] RFC: LoggingEvent redesign

Thorbjoern Ravn Andersen ravn at runjva.com
Tue Feb 24 09:29:36 CET 2009

Ceki Gulcu skrev:
> 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.
Ok.  It is the serialization problem you are looking at.

A brief comment now:  The problem you experience is inherit to Java 
serialization.  If you consider another transport mechanism as the 
default, you may choose one which allows for clients not written in Java 
as the official "talk-to-logback" protocol.    Joern has already 
suggested looking into XMLEncoder/XMLDecoder which may however be too 
slow for your liking.

> 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.
So you want to split out the functionality from the Data Value Object.  
Fine with me :)

> 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.
If you write custom serializer/deserializer and keep a serialversion you 
can do whatever you want :)

  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"

More information about the logback-dev mailing list