Good point about classloading. I'll go ahead with that.
On Jan 13, 2011, at 2:38 PM, Manik Surtani wrote:
It makes sense not to deserialize this in the first place. E.g.,
treat applictaion/x-java-serialized-object the same as application/octet-stream.
Deserializing is a Bad Thing, the server nodes may not even have the necessary class
definitions to be able to deserialize.
On 13 Jan 2011, at 08:44, Galder Zamarreño wrote:
> Hi all,
>
> Re:
https://issues.jboss.org/browse/ISPN-872
>
> As stated in my last comment, it appears to me that Infinispan's REST server is
not distinguishing between a byte array that comes from a Java client that serialized an
object, and a pure byte[] that is not necessarily a serialized form of a Java object.
>
> The test added by Michal might not make sense to a lot of you (
http://goo.gl/8qfnw -
testByteArrayStorage), but the underlying issue is still present.
>
> Looking back at past tests, IntegrationTest.testSerializedObjects is not correct. The
byte array passed is not "application/x-java-serialized-object". In fact, the
server tries to deserialize it and fails, which leads to the byte[] being stored as is,
but still under the "application/x-java-serialized-object" banner.
>
> My question is, what should be the type to use for pure byte arrays? Should it be
"application/octet-stream" ? Any other suggestions?
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache