[JIRA] Created: (LBCLASSIC-163) LoggingEventVO does not serialize the argument array properly.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-163: --------------------------------------- I should add that I have successfully tested the fix by passing LoggingEventVO with an attached StructuredDataImpl through JMSTopicAppender to the JMSTopicSink and properly logging the message on the remote side.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] 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
[ 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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] 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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-163: -------------------------------------- As both Ralph and Joern make valid points, I won't comment further except on PreSerializationTransformer. The remark about the redundancy of PreSerializationTransformer got me thinking. It is needed because logback differentiates between the live event generated locally, i.e. LoggingEvent, and the serialized event, i.e. LoggingEventVO, both of which are implementations of ILoggingEvent, the type expected internally. The question is then why such differentiation is deemed necessary? Couldn't we have LoggingEvent serializable and be done with it? Well, LoggingEvent used to be serializable as it was (and still is) in log4j. However, this makes the code in LoggingEvent more complex and harder to maintain. So the separation is justified by code maintainability. as it allows us to have code which is easier to read and understand. Theoretically it also opens the door for other serialization strategies.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-163: --------------------------------------- I think you missed my point though. Why isn't a Layout sufficient to do the serialization? A Layout's purpose is to simply format the event into something useful for the purpose of the particular Appender. In the JMS case, this is just the message to be sent to the remote side where it can be processed. In some cases this might be an already formatted message and in others it might be desired to have a serialized form of the logging event. But a Layout should be able to handle either case.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-163: -------------------------------------- Yah, I had missed your point. As it stands today, a Layout is only capable of converting a ILoggingEvent instance into a String. We would need to change logback internals so that other transformations are possible.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Maarten Bosteels commented on LBCLASSIC-163: -------------------------------------------- We discussed this before, see http://marc.info/?l=logback-dev&m=124908019606226&w=2 I created another ticket: LBCLASSIC-164
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] 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... 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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn edited comment on LBCLASSIC-163 at 10/24/09 1:30 PM: ------------------------------------------------------------------- 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 Encoder and Decoder (or, if needed, the combined interface Codec) to achieve this: http://sourceforge.net/apps/trac/sulky/browser/trunk/sulky-codec/src/main/ja... 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 Encoders (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 Encoders <String,Object> could be supported in a non-obtrusive way. There are some details missing, though. How can I identify the Encoder used for serialization? How can I find a suitable Decoder 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 Decoder 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. was (Author: jhuxhorn): 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... 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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-163: --------------------------------------- I took the easy way out. 1. I changed LoggingEventVO so that only StructuredData objects are serialized. All others are serialized to Strings as was previously done. 2. JMSTopicAppender, JMSQueueAppender and SocketAppender can be configured with a PreSerializationTransformer. This allows the serialization to be done any way desired. However, SocketNode, JMSTopicSink and JMSQueueSink still do not provide a way to override the way they deserialize objects. I propose adding a DeSerializationTransformer that can be configured in. Alternately, the deserialization method could be added to the PreSerializationTransformer - in which case the PreSerializationTransformer interface name should be renamed. 3. JMSTopicAppender, JMSQueueAppender and SocketAppender all will use the LayoutPreSerializationTransformer if a layout is configured and no PreSerilalizationTransformer is provided.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-163: ----------------------------------------- Just a quick question (I'm on the run and still hadn't time to check out your changes, sorry): Will StructuredData be included in logback-classic? This would at least solve the NoClassDef problem. I could solve any other problems myself, I think. The only downside I still see is that LoggingEventVO will change yet again. A separate implementation might be a better idea.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-163: --------------------------------------- StructuredData is part of the SLF4J API along with StructuredDataId and StructuredDataImpl.
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
[ http://jira.qos.ch/browse/LBCLASSIC-163?page=com.atlassian.jira.plugin.syste... ] Ralph Goers edited comment on LBCLASSIC-163 at 10/26/09 5:35 PM: ----------------------------------------------------------------- StructuredData is part of the SLF4J API along with StructuredDataId and StructuredDataImpl. The fact that LoggingEventVO will change is a downside to using Object serialization at all. Another downside is it makes it difficult for Logback to play nice with non-Java applications. was (Author: rgoers@apache.org): StructuredData is part of the SLF4J API along with StructuredDataId and StructuredDataImpl.
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
participants (4)
-
Ceki Gulcu (JIRA) -
Joern Huxhorn (JIRA)
-
Maarten Bosteels (JIRA)
-
Ralph Goers (JIRA)