[omniORB] Interop between omniORB3 and Java
Jean Francois Poilpret
jfpoilpret@hn.vnn.vn
Thu, 6 Jul 2000 18:39:53 +0700
Hello Sai-Lai,
I just tried the JDK1.3 string_to_object with the IOR you provided: it's =
just the same, java throws the same exception; this makes me think that =
(fortunately), string_to_object does not try to interpret the type id of =
the IOR it is passed.
I also tried what Duncan suggested: generate the same IOR with =
"NameServiceA" key instead of "NameService" and this worked !
So it seems the problem is related to the length of the Object Key in =
the IOR.
I also tried to generate the same IOR with a key of length 10, it is =
also unrecognized (exception thrown).
The conclusion is (just as Duncan suggested):
JavaIDL string_to_object() only works with IORs having an Object Key =
with a length multiple of 4.
in other situations, it is broken.
Today, I will submit a bug report to Sun, regarding that issue.
I hope I will not encounter too many other problems of that kind when =
I'm testing my system ...
Thank you for your valuable support
Best regards
Jean-Fran=E7ois Poilpr=EAt
-----Original Message-----
From: Sai-Lai Lo <S.Lo@uk.research.att.com>
To: Jean Francois Poilpret <jfpoilpret@hn.vnn.vn>
Cc: omniorb-list@uk.research.att.com <omniorb-list@uk.research.att.com>
Date: jeudi 6 juillet 2000 18:06
Subject: Re: [omniORB] Interop between omniORB3 and Java
Hi!
Could you try this IOR with omniORB 3.0 instead of the one emitted by
omniNames:
IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696=
e67436f6e746578743a312e3000010000000000000027000000010100000c000000313932=
2e3136382e302e3100290800000b0000004e616d6553657276696365
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 =
asked
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 =
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
--=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