[
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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
