Assuming an IDL something like this:
valuetype MyClassSequence sequence<MyClass>;
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
Can you provide a standalone compilable test case?