Going from ORBit1 to ORBit2 - does it require any user code changes?

[Anders Selander <selander pdc kth se>]

Hello,

I have a well-functioning server developed with ORBit1 and a collection
of specialised Perl-clients, using CORBA::ORBit 0.4.7. However, I would
like to migrate to ORBit2 for obvious reasons. 

To get the server to compile cleanly with ORBit2, it is enough to edit
the Makefile, changing orbit-config to orbit2-config, orbit-idl to
orbit-idl-2, and adding glib-config in a few places. The server seem
to run smoothly but the clients only work up to a point. Consider this
idl-file excerpt:

        union post switch (short) {

                case 0: string errRes;
                case 1: string strRes;
                case 2: long intRes;
                case 3: double dblRes;
        };

        struct result {

                short columns;
                short rows;
                sequence<string> columnnames;
                sequence<post> posts;
        };

        interface QuerierObj {

                result FreeQuery(in string query);
                ...
        };

In the Perl-clients, after trying $ref = $object->FreeQuery($query)
without catching any CORBA::Exception, it works well both with
ORBit 1 and 2 to access columns, rows, and rownames:

        $$ref{'columns'}
        $$ref{'rows'}
        ${$$ref{"columnnames"}}[$n]

But accessing the posts as below  only works with ORBit1 - with ORBit2
the contents gets garbled, as if the wrong memory is referenced. For
instance, the discriminator often takes a illegal value, rendering the
value-access uninitialized.

        Discriminator: ${${$$ref{"posts"}}[$i]}[0]
        Value:         ${${$$ref{"posts"}}[$i]}[1]

Is not this the right way to decode the individual posts in the above
idl-definition of a result? The result struct becomes a Perl reference
to a hash were we use "posts" as a key to get a reference to a Perl
array containing references to the size-two Perl array representations
of Corba unions - no? (At least the outermost ${ } should be possible
to leave out.)

I hope I have collected enough relevant information. My bottomline
question is whether a switch from ORBit1 to ORBit2 requires some user
code changes in addition to the Makefile-mediated changes the
orbit-config and orbit-idl, respectively orbit2-config, orbit-idl-2,
and glib-config executes? Or might I be wrong thinking that the same
Perl client should work without changes?

Best Regards /Selander, hoping for any valuable input