SourceForge has been redesigned. Learn more.

#2 support for serializing exceptions

toby cabot

I've seen problems where Skaringa gets into an infinite
recursion when it tries to marshal certain objects,
specifically Exception and descendants. After some
investigation it appears that the problem is that the
"cause" of the exception is initialized by default to
itself, so when Skaringa goes to serialize the cause it
gets into an infinite recursion (well, not infinite,
only until the stack overflows).

I'm not sure what the real solution is, but I've
implemented a work-around that seems to work well for
the cases that I've seen. Since the circularity is one
object that references itself in one of its members we
can just check that the member that we're about to
marshal isn't "self". Granted, larger loops (a -> b ->
a) will still cause problems, but those loops would
involve a lot more code to check, and marshalling
Exception can be useful.

This patch is:

- a new Exception test file
- a patch to ObjectSerializer to check for objects
that reference themselves
- a patch to the test cases


  • toby cabot

    toby cabot - 2003-01-13

    additional unit test for Exceptions

  • toby cabot

    toby cabot - 2003-01-13

    unit test object to test Exceptions

  • toby cabot

    toby cabot - 2003-01-13

    check that an object doesn't reference itself

  • Anonymous

    Anonymous - 2003-01-14
    • assigned_to: nobody --> skaringa
    • status: open --> open-accepted
  • Anonymous

    Anonymous - 2003-01-20

    Logged In: YES

    The problem is more complex:

    Skaringa doesn't recognize if two variables contain a reference
    to the same object.
    For example:

    class X {
    Object a, b;

    X(x) {
    a = x;
    b = x;

    Here a and b refer to the same object.
    After serializing and deserializing X, the members a und b
    however contain two different objects. Of cource, these objects
    are EQUAL, but not THE SAME.

    This behavior results in the infinite loop if an object contains a
    reference to itself.

    The solution is to keep track of all objects that are serialized into
    one XML stream and provide an unique ID attribute for those
    objects. If the same object is referenced more than once, then
    the object should be written only once into the XML stream. All
    further references to this objects only contain an IDREF attribute
    which points to the object.

    I will try to add this in r1p7.

  • Anonymous

    Anonymous - 2003-02-01
    • status: open-accepted --> closed-fixed

Log in to post a comment.