[logback-dev] RFC: LoggingEvent redesign

Ceki Gulcu ceki at qos.ch
Thu Feb 26 11:07:00 CET 2009

As an alternative design, appenders doing serialization such as
SocketAppender and JMSQueue/JMSTopicAppender can delegate the
serialization transformation to a sub-component. This way, the
ILoggingEvent interface need not know about serialization at all. The
SDOAware interface can be thus removed.

Much cleaner.

Ceki Gulcu wrote:
> Joern Huxhorn wrote:
>> On 25.02.2009, at 19:33, Ceki Gulcu wrote:
>>> The SDOAware interface contains a single method:
>>> public interface SDOAware {
>>>   Serializable getSDO();
>>> }
>> It's not necessary for the SDO to implement Serializable. This is only 
>> necessary if serialization using ObjectOutputStream is used as the 
>> persistence method, and this should be an implementation detail hidden 
>> from the API.
> The getSDO() returns a Serializable precisely because certain logback
> classes such as SocketAppenderBase in logback-core, and
> JMSQueue/JMSTopicAppender in logback-classic require serializable
> objects just before handing them over to an ObjectOutputStream.
> So as it currently stands (revision 2170), the LoggingEvent hierarchy
> assumes that you can transform a LoggingEvent into a corresponding
> serializable LoggingEvet. As things stand as of revision 2170,
> serialization is not an implementation detail but actually leaks from
> ILoggingEvent interface (because it extends SDOAware).
> I don't personally like this leakage but it is there. I welcome ideas
> about alternative designs where serialization is really an
> implementation detail.
> To give an idea, I've looked at adding a writeResolve method in
> LoggingEvent so as to replace the current LoggingEvent instance with a
> LoggingEventSDO instance. This would obviate the need for the SDOAware
> interface. However, the cost of serialization performance is degraded
> by about 30% which seems to steep a price.
>> Beside that, DTO (http://en.wikipedia.org/wiki/Data_Transfer_Object) 
>> would probably be a better name since it is known to a wider audience.
> Indeed, SDO is probably not a good name. However, aren't DTOs a
> mechanism to aggregate data so as to minimize the number of EJB calls?
> Also, are DTOs serializable by definition? (I guess they are.) Maybe
> VO (Value Object) is a better name than SDO...
>> Regards, Joern.

Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.

More information about the logback-dev mailing list