[ https://issues.jboss.org/browse/ISPN-872?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño edited comment on ISPN-872 at 1/12/11 11:54 AM: ----------------------------------------------------------------- I get the feeling that the issue here is that at read time, we don't differentiate between a pure byte[] which we shouldn't serialize as opposed one that we should: obj match { case ba: Array[Byte] => Response.ok.`type`("application/x-java-serialized-object").entity(streamIt(_.write(ba))).build case ser: Serializable => Response.ok.`type`("application/x-java-serialized-object").entity(streamIt(new ObjectOutputStream(_).writeObject(ser))).build If we send the byte[] as is, then this is not a java serialized object but it could be as shown by this example. So, if someone sends a byte[] as is, which does not come from having serialized an object, a different type is needed here, maybe "application/octet-stream" or some other pure binary MIME type? I must say that I thought that your test is a bit odd and I've wondered if it actually makes sense. If you have String, why convert it to byte array via getBytes() and then serialize it? You can just take the String and serialize it directly and the resulting object is a String on the server side. I guess what the getBytes() gives you is the confidence that it is being transformed into a particular encoding of your preference which in this case is plattform independent, i.e. UTF-8. Odd but I think deep down is a valid use case. was (Author: galder.zamarreno(a)jboss.com): I get the feeling that the issue here is that at read time, we don't differentiate between a pure byte[] which we shouldn't serialize as opposed one that we should: obj match { case ba: Array[Byte] => Response.ok.`type`("application/x-java-serialized-object").entity(streamIt(_.write(ba))).build case ser: Serializable => Response.ok.`type`("application/x-java-serialized-object").entity(streamIt(new ObjectOutputStream(_).writeObject(ser))).build If we send the byte[] as is, then this is not a java serialized object but it could be as shown by this example. So, if someone sends a byte[] as is, which does not come from having serialized an object, a different type is needed here, maybe "application/octet-stream" or some other pure binary MIME type? I must say thought that your test is a bit odd and I've wondered if it actually makes sense. If you have String, why convert it to byte array via getBytes() and then serialize it? You can just take the String and serialize it directly and the resulting object is a String on the server side. I guess what the getBytes() gives you is the confidence that it is transforming into a particular encoding of your type that is plattform independent, i.e. UTF-8. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-872?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-872: --------------------------------------- Actually, the test is not correct. If you're already retrieving the byte[] from getBytes(), why pass it through ObjectOutputStream? That makes no sense at all. Even in the case that you pass getBytes() directly (which I'd add to the testsuite) currently you'd pass the byte[] as "application/x-java-serialized-object" which will probably fail cos the server side will attempt to deserialize which should fail cos it's not really a Java serialized object. So, the root cause is still present, a different type is needed for pure byte[] arrays that are not serialized such as getBytes() result. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-872?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-872: ---------------------------------- Summary: REST server should not deserialize byte arrays (was: In REST, serialized byte array is returned as raw but not serialized) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-872?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-872. ----------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira