Read only archive ; use for new issues
Bug 723 - Boxed valuetype sequences are marshaled incorrectly
Summary: Boxed valuetype sequences are marshaled incorrectly
Status: NEW
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 2.2.4
Hardware: PC All
: P2 normal
Assignee: Gerald Brose
Depends on:
Reported: 2006-09-06 06:55 CEST by Tamas Kerecsen
Modified: 2012-08-19 13:46 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Tamas Kerecsen 2006-09-06 06:55:12 CEST
Assuming an IDL something like this:
valuetype MyClass
   short x;
   string y;
valuetype MyClassSequence sequence<MyClass>;
valuetype MyOtherClass
  long q;
  MyClassSequence seq;

If I try to send MyOtherClass over to another process as a return value or
parameter, MyClassSequence gets serialized with an RMI repository ID instead of
an IDL repository ID. As far as I could decipher, the problem is that while the
Helper class for a regular sequence has special code to iterate through the
elements of the Java array and serialize the objects inside the array, the
Helper for a boxed valuetype sequence doesn't recognize that it's dealing with a
sequence and tries to serialize the MyClassSequence[] array itself as a CORBA
object. Eventually the call to RepositoryID realizes that the array is not a
subclass of an IDL type, and falls back to RMI type IDs (honestly, I should be
able to disable the RMI fallback mechanism altogether).

Obviously the RMI type ID completely freaks out any CORBA implementation
other than JacORB, and leads to a prompt MARSHAL exception on the other

I'm inclined to believe this is a problem in JacORB, because omniORB works
perfectly well with the very same IDL, and even JacORB is entirely happy to
unmarshal objects constructed on the C++ side with valuetype sequences in
them. It's only when I try to send those object back from Java to C++ when I
get a visit from the MARSHAL.

For the time being I worked around the problem by creating zero-length
sequences in case no data is available, but it's more hassle than using
valuetype sequences (since the valuetypes get set to null automatically, saving
a bit of extra initialization).

I've checked the 2.3 nightly a few days ago, and the problem is present in that
version too.
Comment 1 Nick Cross 2012-08-19 13:46:26 CEST
Can you provide a standalone compilable test case?