[logback-dev] [JIRA] Commented: (LBCLASSIC-163) LoggingEventVO does not serialize the argument array properly.

[Joern Huxhorn (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11338#action_11338 ] 

Joern Huxhorn commented on LBCLASSIC-163:
-----------------------------------------

This is in reply to Ralphs comment containing the Event Producers.

Event Producers (and yes, the name might be a little off) contain ServerSockets that accept connections to receive events over the wire.

The one listening on port 4560 is expecting serialized Logback events, as produced by SocketAppender.

The one listening on port 10000 is expecting compressed Lilith Logging events that I serialize as I see fit with my MultiplexLoggingAppender (MA). I use Google Protobuf to achieve this, see http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance for a comparison of different serialization techniques.
I use implementations of Serializer and Deserializer to achieve this:
http://sourceforge.net/apps/trac/sulky/browser/trunk/sulky-generics/src/main/java/de/huxhorn/sulky/generics/io

Both appenders have pros and cons, the MA isn't a replacement of SocketAppender but can be used as such under certain circumstances (see http://sourceforge.net/apps/trac/lilith/wiki/AppenderPitfalls and http://sourceforge.net/apps/trac/lilith/wiki/MultiplexAppenderBackground ).

To wrap it up:
You are best of using SocketAppender if you have a short running console-application or JUnit testcase with only one recipient of events, like localhost.
If you have a long-running application like a webapp and/or have a large amount of recipients then you'll be better of using my MA.

Concerning the original bug report:
I think it would be a good idea to have a place to define Serializers (or whatever interface is used for the purpose) for classes. If those are defined in the appenders it would be possible to use them for that appender, alone.
If they are defined globally, e.g. in the LoggerContext, then it would also be possible to use them for MDC. SLF4J/Logback has a <String, String> MDC while Log4J had a <String,Object> one. Using Serializers <String,Object> could be supported in a non-obtrusive way.

There are some details missing, though.
How can I identify the Serializer used for serialization? How can I find a suitable Deserializer in a platform-neutral way? etc.
In my MA, I'm expecting a well-known serialized message but in case of serialized arguments this would have to be pluggable with a "I don't understand it so I simply won't care about it until I know about it" mentality.
What I mean with that is that I need to receive the events and store them even if I don't fully understand everything that's contained in them. If, at a later point, a Deserialzer for one of the arguments is added, then I'd like to be able to handle previously received events containing those arguments, too.
Therefore, serialized arguments should be byte[] with some additional information about the way they were serialized.

Unlike the original SocketAppender I'm aiming for platform/language-independence. Java Serialization isn't able to provide that.

> 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