[ http://jira.qos.ch/browse/LBCLASSIC-201?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-201: ----------------------------------------- Not a good idea. This would result in an ClassNotFoundException if the class of the arguments is not available in the receiving application, e.g. http://lilith.huxhorn.de or Eclipse Console plugin.

Preferably don't call toString() on objects in arguments array --------------------------------------------------------------

Key: LBCLASSIC-201 URL: http://jira.qos.ch/browse/LBCLASSIC-201 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.19 Environment: Software platform Reporter: Donald Graham Assignee: Ceki Gulcu

I'm attempting to use a SocketAppender to send log events over the network to a custom appender hosted by SimpleSocketServer. My custom appender needs to work with my arguments as objects, rather than strings. I noticed that the string representations of my arguments were being passed across the network, and traced through to the code shown below (from ch.qos.logback.classic.spi.LoggingEventVO). Would you consider sending the object's serialized form instead (assuming the object is serializable)? private void writeObject(ObjectOutputStream out) throws IOException { out.defaultWriteObject(); out.writeInt(level.levelInt); if (argumentArray != null) { int len = argumentArray.length; out.writeInt(len); for (int i = 0; i < argumentArray.length; i++) { if (argumentArray[i] != null) { out.writeObject(argumentArray[i].toString()); } else { out.writeObject(NULL_ARGUMENT_ARRAY_ELEMENT); } } } else { out.writeInt(NULL_ARGUMENT_ARRAY); } }

-- 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-201?page=com.atlassian.jira.plugin.syste... ] Rü commented on LBCLASSIC-201: ------------------------------ I think that common Java types like Long, Calendar, java.sql.Date, etc. should be considered safe by default. The common way to specify which classes are safe would be to configure it in some file on the client. I think this should not be by class nor by package name but by jar, and include a version string. But it would be much nicer for the client and server to do a hand-shake to automagically aggree on the list of safe jars: When the client starts, it asks the server for the list of jars that it knows about. It then transmits all instances of classes from matching jars in serialized form. The list would preferably not contain the file name of a jar but data from it's manifest. You can get a list of all available manifests by calling classLoader.getResources("META-INF/MANIFEST.MF"). If it contains a Bundle-SymbolicName and Bundle-Version, use that; if it contains Implementation-Title and Implementation-Version, use that. If it contains none of these, log a warning and use the jar name.

Preferably don't call toString() on objects in arguments array --------------------------------------------------------------

Key: LBCLASSIC-201 URL: http://jira.qos.ch/browse/LBCLASSIC-201 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.19 Environment: Software platform Reporter: Donald Graham Assignee: Ceki Gulcu

I'm attempting to use a SocketAppender to send log events over the network to a custom appender hosted by SimpleSocketServer. My custom appender needs to work with my arguments as objects, rather than strings. I noticed that the string representations of my arguments were being passed across the network, and traced through to the code shown below (from ch.qos.logback.classic.spi.LoggingEventVO). Would you consider sending the object's serialized form instead (assuming the object is serializable)? private void writeObject(ObjectOutputStream out) throws IOException { out.defaultWriteObject(); out.writeInt(level.levelInt); if (argumentArray != null) { int len = argumentArray.length; out.writeInt(len); for (int i = 0; i < argumentArray.length; i++) { if (argumentArray[i] != null) { out.writeObject(argumentArray[i].toString()); } else { out.writeObject(NULL_ARGUMENT_ARRAY_ELEMENT); } } } else { out.writeInt(NULL_ARGUMENT_ARRAY); } }

-- 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-201?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-201: -------------------------------------- Joern's concern about missing types on the receiver end corrupting the stream raises a valid point. Expecting the receiver to handle all possible types will not work and will certainly not scale. However, the receiver can simply step over unknown types. Whenever ObjectInputStream.getObject throws ClassNotFoundException the receiver simply continues reading the next item avoiding the corruption of the input stream. I believe that the readResolve method in LoggingEventVO could be enhanced to deal with ClassNotFoundExceptions. As for Rudigers proposal for the sender and receiver negotiating the types to serialize, the current protocol for event serialization does not require a back channel from the receiver back to the client, so negotiation is not possible without changing the protocol. Even if the protocol were changed, the absence of the back channel allows deferred processing. (The sender writes to a file and the receiver processes the file at a later time.) IMO, the user should be able to specify a serialization contract and the receiver must be able to deal with broken contracts.

Preferably don't call toString() on objects in arguments array --------------------------------------------------------------

Key: LBCLASSIC-201 URL: http://jira.qos.ch/browse/LBCLASSIC-201 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.19 Environment: Software platform Reporter: Donald Graham Assignee: Ceki Gulcu

I'm attempting to use a SocketAppender to send log events over the network to a custom appender hosted by SimpleSocketServer. My custom appender needs to work with my arguments as objects, rather than strings. I noticed that the string representations of my arguments were being passed across the network, and traced through to the code shown below (from ch.qos.logback.classic.spi.LoggingEventVO). Would you consider sending the object's serialized form instead (assuming the object is serializable)? private void writeObject(ObjectOutputStream out) throws IOException { out.defaultWriteObject(); out.writeInt(level.levelInt); if (argumentArray != null) { int len = argumentArray.length; out.writeInt(len); for (int i = 0; i < argumentArray.length; i++) { if (argumentArray[i] != null) { out.writeObject(argumentArray[i].toString()); } else { out.writeObject(NULL_ARGUMENT_ARRAY_ELEMENT); } } } else { out.writeInt(NULL_ARGUMENT_ARRAY); } }

-- 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-201?page=com.atlassian.jira.plugin.syste... ] Joern Huxhorn commented on LBCLASSIC-201: ----------------------------------------- How about leaving the current SocketAppender as it is and implementing any more complex logic in a different SocketAppender implementation? I really think that most use-cases of the SocketAppender won't need serialized parameters and changing the behavior of SocketAppender will render current receivers broken. This might be a use-case for a different LoggingEventVO implementation. readResolve is called after successful deserialization. you'd need to implement readObject and writeObject in a way that handles the parameters manually, declaring them transient in the class. One remaining problem will be that any parameters that throw a ClassNotFoundException while deserializing won't be available in the parameters array, obviously. Those may have included very important information that won't show up in the log message anymore, though! All of this is making me a bit nervous... that's why I'd suggest to keep the KISS implementation of SocketAppender and putting anything else into a completely different one, instead.

Preferably don't call toString() on objects in arguments array --------------------------------------------------------------

Key: LBCLASSIC-201 URL: http://jira.qos.ch/browse/LBCLASSIC-201 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.19 Environment: Software platform Reporter: Donald Graham Assignee: Ceki Gulcu Attachments: SerializationTest.java

I'm attempting to use a SocketAppender to send log events over the network to a custom appender hosted by SimpleSocketServer. My custom appender needs to work with my arguments as objects, rather than strings. I noticed that the string representations of my arguments were being passed across the network, and traced through to the code shown below (from ch.qos.logback.classic.spi.LoggingEventVO). Would you consider sending the object's serialized form instead (assuming the object is serializable)? private void writeObject(ObjectOutputStream out) throws IOException { out.defaultWriteObject(); out.writeInt(level.levelInt); if (argumentArray != null) { int len = argumentArray.length; out.writeInt(len); for (int i = 0; i < argumentArray.length; i++) { if (argumentArray[i] != null) { out.writeObject(argumentArray[i].toString()); } else { out.writeObject(NULL_ARGUMENT_ARRAY_ELEMENT); } } } else { out.writeInt(NULL_ARGUMENT_ARRAY); } }

-- 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