It's a difficult issue.

Because Hessian uses reflection, it really wants a zero-arg constructor for 
everything.  When it can't find one, it searches for the next best constructor 
it can find.  (Not optimal, but it works for several cases.)

java.io serialization cheats.  It can instantiate objects using JNI calls, 
skipping the constructors entirely.  Hessian can't do that.

Now, I do think we can improve the custom deserialization factories from the 
current Hessian implementation, e.g. more of a JavaBeans PropertyFactory style, 
so the custom converter is automatically discoverable by classname, not 
requiring registration.

In the case of Throwables, it might make sense to add a standard deserializer 
that looks for the standard this.cause field, and always tries to use that 
constructor if the zero-arg one is missing.  It's a bit of a hack, though.

-- Scott

Mattias Jiderhamn <[EMAIL PROTECTED]> wrote: There is a problem in 
deserializing NestableException (and
NestableRuntimeException and NestableError) from Jakarta Commons Lang.
These are used extensively within Hibernates exception hierarchy.

Here is a testcase:

import org.apache.commons.lang.exception.NestableRuntimeException;
import java.io.*;

public class HessianNestableTest extends TestCase {

    public void testNestableInHessian() throws Throwable
    {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        HessianOutput out = new HessianOutput(baos);

        Exception e = new NestableRuntimeException("Bar");
        e.getStackTrace();

        out.writeObject(e);

        ByteArrayInputStream bain = new
ByteArrayInputStream(baos.toByteArray());
        HessianInput in = new HessianInput(bain);

        Exception ex = (Exception) in.readObject();
        assertEquals("Bar", ex.getMessage());
    }
}

Regardless of whether Hessian 1 or 2 is used, the constructor of
org.apache.commons.lang.exception.NestableDelegate will throw an
exception, since it expects a Throwable (the owning instance!) to be
passed as argument, while null is actually passed by Hessians
deserializer. ("The Nestable implementation passed to the
NestableDelegate(Nestable) constructor must extend java.lang.Throwable").

I have not yet been able to figure out why null is passed, or how this
is supposed to work. Maybe I could write a deserializer that skips the
NestableDelegate attribute and then sets it after everything else is
deserialized???
Has anyone else ran into this problem and know of a workaround...?

 /Mattias


_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest

_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest

Reply via email to