[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.
http://logback.qos.ch


More information about the logback-dev mailing list