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

[John D. Heintz]

Duncan Grisby wrote:

> 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 {};
> 

Shouldn't the client side be forced to call narrow() to get an A 
reference?  Or are you saying the server may not want to publish that 
reference?

> 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.

Does this mean that the server ORB should check _is_a() and raise an 
exception?  The behavior we are seeing is that the the call is making it 
all the way into our python servant with the wrong type of object.  We 
can call _is_a() or isinstance() ourselves, but that seems wrong.

>

> 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.

Unfortunate indeed.  Thanks though Duncan.

John

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m