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!"
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
