[omniORB] Interop between omniORB3 and Java

[Sai-Lai Lo]

Hi!

Could you try this IOR with omniORB 3.0 instead of the one emitted by
omniNames:

IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e6=
7436f6e746578743a312e3000010000000000000027000000010100000c0000003139322e31=
36382e302e3100290800000b0000004e616d6553657276696365

This IOR use the type id "IDL:omg.org/CosNaming/NamingContext:1.0", the
other parts are the same as your original.

I have a suspucion that jdk 1.3 does not handle derived interface well.
When it sees the omniORB 3.0 IOR, it should have contacted omniNames and as=
ked
if it is the type it is expecting,
i.e. "IDL:omg.org/CosNaming/NamingContext:1.0"  instead of just dying
horribly.

Sai-Lai


>>>>> Jean Francois Poilpret writes:

> 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 ali=
gnment problems (with regards to the Java exception thrown: ArrayIndexOutOf=
BoundsException)

> 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-lis=
t@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 t=
he
> 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 mig=
ht
> 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







--=20
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com=
=20
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND