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

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

If we revert this to Java Serialization then the deserializing of a 
LoggingEvent is only possible if both source and receiver of the event have the 
exact same class in their classloader.
Otherwise, the deserialization of the whole event will fail - which creates a 
rather big burden in case of Lilith.

I haven't yet taken a look at your changes in GIT, so you may have thought 
about this already and circumvented it somehow. I've also only taken a quick 
look at RFC 5424 ( http://tools.ietf.org/html/rfc5424 ) so I might miss 
something on that part, too.

Nevertheless, I wanted to voice a quick "Uh oh" before this is introduced into 
Logback.

This would probably be a case for different implementation of ILoggingEvent.
It would give appenders the opportunity to use the value object that it 
needs/would like to use.

Another thing I was already thinking about is the global definition of Codecs 
for certain classes. This would primarily mean that a different technology than 
Java Serialization could (and should) be used for serialization of objects, 
changing the (Java) serialized data to byte[]. I'm thinking about protobuf here.

I'm a bit sick right now so it's possible that I don't make too much sense.
I'd like to discuss that topic further, though.

> 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

        
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev

Reply via email to