Orbix2.3MT interoperability with OmniNames

[Eoin Carroll]

Chris -
> 
> My project has been using OmniNames 2.2.0, OrbixWeb3.0, OrbixC++2.2c01
> quite successfully for a number of months. We have now run into the
> 2.2c01 bug with Any types and have had to move to Orbix2.3MT.
> 
> At the bottom of you interoperability with Orbix2.3 post you mentioned
> that the 2.1 fixes only work in a limited number of circumstances. Could
> you please explain the circumstances.
> 
> Our experience so far has been:
> After applying your suggested 2.1 fixes we could string_to_object and narrow
> successfully the IOR string for omniNames root context. If a sub-context
> exists trying to resolve that sub-context would end with an exception being 
> thrown in decoding of the return value. If a sub-context did not exist trying 
> to bind_new_context would also throw trying to decode the return value.
> 
> Trying to use the omniNames 2.4.0 (org.omg prefix) and the initial string_to_object
> failed.
> 
> Is this consistant with your observations?

This is precisely what I observed. Using Orbix stubs (with the fix applied)
and an omniNames built without the omg.org prefix would allow binding and 
resolving of objects to/from the root context.
 
Trying to resolve a sub-context of the root would fail, with an exception 
being thrown. This appears to be because Orbix 2.3 corrupts the IORs of
sub-contexts it receives from omniNames.

If an Orbix program was linked with Naming stubs built with the omg.org prefix,
and supplied with an omniNames root context IOR (where omniNames also uses 
stubs built with the omg.org prefix), it would, as you observed, fail 
straight away.

Thus, the circumstances in which Orbix 2.3 interoperates are more limited than
Orbix 2.1 (and far more limited than Orbix 2.2).

As a matter of interest, what is the Orbix2.2 type Any bug ? 
Note that if you are using type Any while interoperating between the 
omniORB 2.5 pre-release and Orbix, you should specify -ORBtcAliasExpand 1
on the command-line of the omniORB executable. This strips tk_alias TypeCodes
from the TypeCodes in anys generated by omniORB (Orbix IIOP implementation
doesn't support tk_alias).
 
Regards,

Eoin Carroll

--
Eoin Carroll                                     ewc@orl.co.uk
Research Engineer
Olivetti & Oracle Research Lab
Cambridge, UK