RE: Hessian and JMX Remoting (JSR 160) - Serialization

Hi Scott,

thanks for the reply !

> > As an example, javax.management.ObjectName does not have any
> > serializable field, nor in MX4J nor in JMXRI. As a result,
> > Hessian does not serialize anything for it.
> > Furthermore, Hessian way to deserialize is to lookup a
> > constructor with parameters and instantiate the object
> > passing null for all arguments, and then setting the fields
> > via reflection.
>
> True. The Java serialization of JRMP cheats by calling JNI
> to instantiate the object without actually initializing it.
> Normal Java code (like Hessian) does have that ability.

Does *not* have that ability ?

> In the case of classes like ObjectName, the best solution is
> probably to use readObject/writeObject.

I don't follow.
How can I use readObject/writeObject with Hessian if not passing the java-serialized bytes (and thus disallowing other languages to communicate) ?

> > At the beginning I thought to write a
> > serializer/deserializer pair for
> > each JMX class: a loong long way :(
>
> I don't understand why this would be necessary. As I
> remember, there's only a limited API needed for JMX remoting,
> so there shouldn't be all that many classes which need
> special treatment.

Here's what I've found.
I have written a custom serializer/deserializer for ObjectName.
Then I have JSR 160 methods that return - for example - ObjectInstance, another JMX class, that has 2 data member: a String and an ObjectName.
I thought that Hessian should be able to handle this case, but in fact it's doing this (pseudo-code):

ObjectInstance oi = new ObjectInstance(null, null);
field1.set(oi, objectName);
field2.set(o1, string);

Unfortunately, new ObjectInstance(null, null) throws an exception because the arguments cannot be null (this is required by the spec).

This requires writing a custom serializer/deserializer for ObjectInstance as well, AFAIK.
Counting the fact that almost every concrete serializable JMX class is doing these checks in the constructor, and that all of them depends heavily on ObjectName/ObjectInstance/MBeanInfo, I realized that writing a custom serializer/deserializer for each serializable JMX class was a looong long way (as already has been with SOAP and Axis).
For the record there are more than 50 serializable classes in JMX.

> > But then I discovered that Throwables are not deserialized
> > correctly.
> > This is due to a probable bug in
> > com.caucho.hessian.io.SerializerFactory: methods
> > getSerializer(Class) and getDeserializer(Class) are not symmetric.
> > Throwables are treated in one way in one method, and
> > forgotten in the second :(
>
> The special code is different in each direction. The
> Throwable serializes easily, but the deserialization is
> tricky since the StackTraceElement isn't instantiable, so
> Hessian needs to create a dummy Java serialization stream to creat it.
>
> Most of the Throwable deserialization works without special
> code, it's just the StackTraceElement that's a problem.

I'm not sure I follow.
You say that the stackTraceElement bit is the one that forces Throwables to be serialized with ThrowableSerializer, but deserialized with JavaDeserializer ?

Many thanks !

Simon
Received on Thu 05 Aug 2004 01:10:20 -0700