[omniORB] Interop between omniORB3 and Java

Jean Francois Poilpret jfpoilpret@hn.vnn.vn
Thu, 6 Jul 2000 16:38:31 +0700


Hi Roumen,

that's right, but I'm not sure this is the actual problem, since, AFAIK, =
string_to_object() should not be affected by the typeid of its object =
(only _narrow() should be, shouldn't it ?).

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

Thank you for your concern

Regards

    Jean-Fran=E7ois Poilpr=EAt

-----Original Message-----
From: Ivanov, Roumen <Roumen.Ivanov@dresdner-bank.com>
To: 'Jean Francois Poilpret' <jfpoilpret@hn.vnn.vn>; omniORB =
<omniorb-list@orl.co.uk>
Date: jeudi 6 juillet 2000 15:42
Subject: RE: [omniORB] Interop between omniORB3 and Java


Hi,
both 2.8 and JDK IORs contain at offset +8
TypeId value: 'IDL:omg.org/CosNaming/NamingContext:1.0.'

3.0 IOR contains at the same offset
TypeId value: 'IDL:omg.org/CosNaming/NamingContextExt:1.0.'

Regards,
Roumen

-----Original Message-----
From: Jean Francois Poilpret [SMTP:jfpoilpret@hn.vnn.vn]
Sent: Thursday, July 06, 2000 08:17
To: omniORB
Subject: [omniORB] Interop between omniORB3 and Java

Hi omniORB'ers,

recently, I started to upgrade the tools I'm using for developping my
system.

I'm working with Linux 2.2, glibc 2.1 and gcc 2.95.2

Previously, I was using omniORB 2.8 for the C++ part, and jdk 1.2.2 and
ORBACUS 3.3.1 for the Java part.
Besides interoperability issues related to the Name Service (omni 2.8 is =
not
INS compliant), there was no problem with that configuration.

Then, I upgraded to omniORB 3.0 (may, 26th snapshot) and JDK 1.3 (beta
release for Linux) and decided to throw away ORBACUS, since the JDK
integrated ORB seems OK, now (compared with the one in JDK 1.2...)

Unfortunately, the issue regarding operability with the Name Service
remains, since in JDK 1.3, the ORB is far from INS-compliant :-(
However, this is not my actual problem here ; I just decided to go with =
the
usual workaround:
use omniNames 3.0
get the IOR
pass the IOR as an arg to the Java client
convert the IOR with string_to_object, and narrow it to NamingContext

The problem I ran into is with the IOR to the root NamingContext of
omniNames 3.0: this IOR cannot be converted by string_to_object in JDK =
1.3 !

I checked this IOR with catior, and with other 3rd party tools and there
seems to have no problem at all with it.

But with JDK 1.3, I get the following exception

java.lang.ArrayIndexOutOfBoundsException
at com.sun.corba.se.internal.util.Utility.bytesToInt(Utility.java:1032)
at
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStream.=
jav
a:600)
at
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStream.=
jav
a:572)
at com.sun.corba.se.internal.corba.ORB.string_to_object(ORB.java:1017)
at toto.main(toto.java:9)
Exception in thread "main"=20

the weird thing is that I tried the string_to_object function with an =
IOR
coming from omniNames 2.8 and it worked perfectly !

I also checked that with the final release of JDK 1.3 for Windows, and =
it
just behaved the same: the omniNames 3.0 IOR cannot be converted.

Before submitting a bug report to Sun, does somebody know if this IOR =
might
be malformed, but in such a way that most tools don't care, except JDK =
1.3 ?

Here is the IOR given by omniNames 3.0 (the one which does not work):

IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616
d696e67436f6e746578744578743a312e300000010000000000000027000000010100
000c0000003139322e3136382e302e3100290800000b0000004e616d6553657276696365

And the IOR given by omniNames 2.8 (this one works right):

IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616
d696e67436f6e746578743a312e3000010000000000000028000000010100000c0000
003139322e3136382e302e3100393000000c0000003940d4c7cc9bf18800000002

For information, here is the IOR given by tnameserv (the Name Service
provided with JDK):

IOR:000000000000002849444c3a6f6d672e6f72672f436f734e616d696e672f4e616
d696e67436f6e746578743a312e300000000001000000000000005400010100000000
0c3139322e3136382e302e31000401000000000018afabcafe000000026a873e02000
000080000000000000000000000010000000100000014000000000001002000000000
0001010000000000

Anyone has ideas ?

Thank you

    Jean-Fran=E7ois Poilpr=EAt