[omniORB] Extending a union by a member - is a mismatch btw. server and client IDL allowed?

[Martin B.]

Duncan, thanks. Great explanation as ever!

I did test the case where the sender sends the union with a 
discriminator value that wasn't defined in the receivers IDL.

On omniORB, this causes a marshalling exception of some sort.

I'm fine with *any* System Exception, since from the receivers view, 
anything the sender sends that isn't in its IDL is just garbage.

On the other hand, I think a crash for *any* malformed GIOP data would 
be a sign of a poor implementation. I'd call it a bug.

I guess there's nothing but trying the ORB combinations I'm interested 
in to have proof that it does work withing reasonable limits.

Aside:

I've always taken it for granted that adding a new method to an 
interface (just adding at the end of the definition on the server side) 
is essentially a compatible change.

 From what you said, "it is illegal to have differing IDL" it seems this 
is also just an artefact of how GIOP is defined?

cheers,
Martin


On 21.08.2012 11:23, Duncan Grisby wrote:
> On Mon, 2012-08-20 at 12:24 +0200, Martin B. wrote:
>
>> Is a client compiled with v1-1.idl supposed to be able to talk to a
>> server compiled with v1-2.idl -- where the definition of the union (and
>> the enum) differ but are a pure addition to the existing interface?
>>
>> Can a client correctly invoke GetValue() as long as this function
>> doesn't return a unknown datatype?
>>
>> Is this covered by the CORBA spec at all?
>
> The CORBA spec says that it is illegal to have differing IDL on client
> and server. However, as long as they are communicating with GIOP, you
> will get away with it. The on-the-wire format for unions just sends the
> discriminator followed by the value associated with that discriminator.
> As long as the receiver gets a discriminator and value it knows, it will
> never know that the sender had a different definition.
>
> With an enum discriminator, you must extend it by adding items to the
> end of the enum. Enums are sent by numerical value, so if you modify the
> order of the enum, the values will be misinterpreted.
>
> You will of course be in real trouble if the receiver gets a union value
> with a discriminator it didn't expect. Exactly what will happen depends
> on the IDL definitions and how the receiving ORB handles the unexpected
> marshalled data. You may get various different exceptions or even crash.
>
> Cheers,
>
> Duncan.
>