[omniORB] Interop between omniORB3 and Java

Jean Francois Poilpret jfpoilpret@hn.vnn.vn
Thu, 6 Jul 2000 13:17:11 +0700


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.=
java:600)
 at =
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStream.=
java: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