[omniORB] Interop between omniORB3 and Java

[Duncan Grisby]

On Thursday 6 July, "Jean Francois Poilpret" wrote:

> I was thinking about a potential problem of missing padding bytes, or
> alignment problems (with regards to the Java exception thrown:
> ArrayIndexOutOfBoundsException)

I think it's extremely unlikely that there's anything wrong with the
omniNames IOR. I can think of two possible bugs in JavaIDL which might
be causing the problem. First, with both the 2.8 and Java IORs, the
object key length is a multiple of 4 -- 12 bytes for omniORB 2.8, and
24 bytes for Java. The key in 3.0 is 11 bytes (it's the string
"NameService"). Maybe JavaIDL is confused about alignment after the 11
byte key.

The second possibility is the fact that the 3.0 IOR is of type
NamingContextExt. Normally, you'd expect string_to_object() to cope
fine with a type id it didn't recognise, but maybe JavaIDL does
something special for repository ids with prefix omg.org. That seems
pretty tenuous, though.

You can experiment with both of these possibilities using genior to
create object references to feed to string_to_object(). For example,
the following will create an IOR similar to the omniNames 3.0 one, but
with a 12 byte object key

genior IDL:omg.org/CosNaming/NamingContextExt:1.0 <IP addr> 2089 NameServiceA

Such an IOR refers to a non-existent object, of course, but you can
see if it passes string_to_object(). Similarly, you can create an IOR
with type NamingContext, rather than NamingContextExt, and see what
happens.

Cheers,

Duncan.

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