[
http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11333#action_11333
]
Ralph Goers commented on LBCLASSIC-163:
---------------------------------------
OK. I admit that you got me curious and thinking about this so I went the the
Lilith web site. I didn't see any documentation there though so I downloaded
the product. In the help documentation I see info on how to configure a Lilith
appender. I presume that that would serialize events however it wants so that
wouldn't have this problem. But there is also a section on Event Producers that
I found extremely confusing. Why would Lilith be creating events and starting a
bunch of servers to do it? Are those really event consumers?
Even though I don't particularly need it for my use case, I'm going to look
into this issue some more. I can see how the flexibility to serialize or not
depending on the needs of the receiver could be important.
> 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