[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-163: --------------------------------------- No matter what serialization scheme you pick I'd be willing to bet there is going to be a problem if the source and receiver don't match. Making it impossible to reconstruct the original object is not a viable workaround (which is the way it is now). I can certainly understand why you wouldn't want to be required to have all these classes, but in the case of Lilith I would expect you don't really want a serialized ILoggingEvent either. I assume you would just prefer a well defined data structured such as that provided by RFC 5424. To be honest, I don't understand why JMSTopicAppender and JMSQueueAppender use a PreSerializationTransformer. I would have expected that instead they would just be configured with a SerializedEventLayout. Having to create a LayoutPreSerializationTransformer seemed very redundant. Ideally, the SerializedEventLayout could then be extensible/configurable to allow various serialization methods.
LoggingEventVO does not serialize the argument array properly. --------------------------------------------------------------
Key: LBCLASSIC-163 URL: http://jira.qos.ch/browse/LBCLASSIC-163 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.917 Reporter: Ralph Goers Assignee: Logback dev list
LoggingEventVO serializes the objects in the argument array by simply calling toString(). This makes it impossible to reconstruct the objects on the remote side. I have fixed this in my fork at git://github.com/rgoers/logback.git by serializing the object if it implements Serializable and converting it to a String if it does not.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira