[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:
>> 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