[omniORB] Help, this should never happen but...

[Duncan Grisby]

On Thursday 29 March, "Joshua Reynolds" wrote:

> We are running the windows version of omniORBpy 1.3 and getting some
> seriously bad behaviour.
> 
> omniORB is allowing us to pass the wrong kind of object into request.

Unfortunately, omniORB has to allow that due to the specification of
CORBA object references. An object reference basically contains two
pieces of information: the object's type, and information to locate
the object. The type is sent as a repository id string. The problem
comes from section 13.6.2 of the spec:

  "The type ID, if provided by the server, indicates the most derived
   type that the server wishes to publish, at the time the reference
   is generated. The object's actual most derived type may later
   change to a more derived type. Therefore, the type ID in the IOR
   can only be interpreted by the client as a hint that the object
   supports at least the indicated interface. ..."

So, imagine we have two interfaces:

  interface A { ... };
  interface B { ... };

and an operation expecting an A:

  void op(in A the_A);

Now, we're holding an object reference of type B, and pass it to op().
Neither the sending or receiving ORB can complain at this stage, since
the object might actually have interface C:

  interface C : A, B {};

All the receiving ORB can do is mark the object reference as having
its type unverified. On the first call to the object, its type is
checked with a call to _is_a(), and an INV_OBJREF exception is thrown
if the type is incorrect.

This is all very unfortunate since it is extremely unlikely that
anyone would ever do such an unpleasant thing with their object
references. It is almost certainly an application bug if someone
passes an object reference which seems to be the wrong type, but the
ORB can't complain just in case it's intentional.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --