[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