[omniORB] Java client connect to OmniORB 4 server, error...

[Rainer Frohnhoefer]

--Apple-Mail-2--349742633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	delsp=yes;
	charset=ISO-8859-1;
	format=flowed


Am Montag, 09.09.02 um 19:08 Uhr schrieb Marcus MacWilliam:
[snip]

> CORBA initialisation exception: org.omg.CORBA.INV_OBJREF:=A0=A0 minor =20=

> code: 1398079490=A0 completed: No
> org.omg.CORBA.INV_OBJREF:=A0=A0 minor code: 1398079490=A0 completed: =
No
> =A0=A0=A0=A0=A0=A0=A0 at =20
> =
com.sun.corba.se.internal.core.CodeSetComponentInfo.read(CodeSetCompone=20=

> ntInfo.java:90)
> =A0=A0=A0=A0=A0=A0=A0 at =20
> com.sun.corba.se.internal.core.Profile.<init>(Profile.java:109)
> =A0=A0=A0=A0=A0=A0=A0 at =
com.sun.corba.se.internal.core.IOR.getProfile(IOR.java:273)
> =A0=A0=A0=A0=A0=A0=A0 at =20
> =
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStrea=20=

> m.java:591)
> =A0=A0=A0=A0=A0=A0=A0 at =20
> =
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStrea=20=

> m.java:577)
> =A0=A0=A0=A0=A0=A0=A0 at =20
> com.sun.corba.se.internal.corba.ORB.string_to_object(ORB.java:1070)
> =A0=A0=A0=A0=A0=A0=A0 at OoApiTest.getCORBAObject(OoApiTest.java:6853)
> =A0=A0=A0=A0=A0=A0=A0 at OoApiTest.main(OoApiTest.java:11054)
>
> Does anyone know why this has started happening. This code has worked
> with the following before:
>
> Client=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Server
> ------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------
> JDK 1.2=A0=A0=A0 and VisiBroker v3.3.3.
> JDK 1.2.2 and VisiBroker v3.3.4.
> JDK 1.3.1 and OmniORB v3.0.4.
> JDK 1.3.1 and OmniORB v3.0.5.
>
> Does OmniORB v4.0.b2 write the IOR in a completely different format? =20=

> It is
> currently writing out the following:
>
> =
IOR:000000000000002449444c3a676f746869632f636f7265782f476f7468696344617=20=

> =
461626173653a312e3000000000010000000000000070000102000000000d3139322e31=20=

> 36382e36302e3
> =
30000a1ec00000019ff6f6f2d746f6f6c6b6974fe3d7cd1229312000100000000000000=20=

> =
000000000200000000000000080000000041545400000000010000001c0000000000010=20=

> 0010000000105
> 010001000101090000000100010109

  It's not the IOR's fault, or, at least, only partially. IIRC, the  =20
Java ORBs prior to version 1.4 had trouble handling IORs with embeded =20=

codeset info. It's been a while since I ran into this problem, but I =20
think omniRB3 uses IIOP1.0 which doesn't have codeset info. omniORB4 =20
'speaks' the newer version of the protocol. The rather brittle ORB that =20=

comes with JRE1.[23].x pretends to understand IIOP1.1 while he really =20=

doesn't and then chokes on the IOR.

  Can you upgrade to another ORB? Else, there might be an option in =20
omniORB4 to switch back to IIOP1.0, which might help.

  If the above explanation was nonsense, forgive me. I ran into that =20
problem some time ago, switched ORBs and happily forgot everythig about =20=

it :)


Regards,
	Rainer.


--Apple-Mail-2--349742633
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1



Am Montag, 09.09.02 um 19:08 Uhr schrieb Marcus MacWilliam:

[snip]


<excerpt><fixed><bigger><bigger>CORBA initialisation exception:
org.omg.CORBA.INV_OBJREF:=A0=A0 minor code: 1398079490=A0 completed: No

org.omg.CORBA.INV_OBJREF:=A0=A0 minor code: 1398079490=A0 completed: No

=A0=A0=A0=A0=A0=A0=A0 at
=
com.sun.corba.se.internal.core.CodeSetComponentInfo.read(CodeSetComponentI=
nfo.java:90)

=A0=A0=A0=A0=A0=A0=A0 at
com.sun.corba.se.internal.core.Profile.<<init>(Profile.java:109)

=A0=A0=A0=A0=A0=A0=A0 at =
com.sun.corba.se.internal.core.IOR.getProfile(IOR.java:273)

=A0=A0=A0=A0=A0=A0=A0 at
=
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStream.j=
ava:591)

=A0=A0=A0=A0=A0=A0=A0 at
=
com.sun.corba.se.internal.iiop.CDRInputStream.read_Object(CDRInputStream.j=
ava:577)

=A0=A0=A0=A0=A0=A0=A0 at
com.sun.corba.se.internal.corba.ORB.string_to_object(ORB.java:1070)

=A0=A0=A0=A0=A0=A0=A0 at OoApiTest.getCORBAObject(OoApiTest.java:6853)

=A0=A0=A0=A0=A0=A0=A0 at =
OoApiTest.main(OoApiTest.java:11054)</bigger></bigger></fixed>


Does anyone know why this has started happening. This code has worked

with the following before:


Client=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Server

------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------

JDK 1.2=A0=A0=A0 and VisiBroker v3.3.3.

JDK 1.2.2 and VisiBroker v3.3.4.

JDK 1.3.1 and OmniORB v3.0.4.

JDK 1.3.1 and OmniORB v3.0.5.


Does OmniORB v4.0.b2 write the IOR in a completely different format?
It is

currently writing out the following:


=
IOR:000000000000002449444c3a676f746869632f636f7265782f476f7468696344617461=
626173653a312e3000000000010000000000000070000102000000000d3139322e3136382e=
36302e3

=
30000a1ec00000019ff6f6f2d746f6f6c6b6974fe3d7cd1229312000100000000000000000=
000000200000000000000080000000041545400000000010000001c0000000000010001000=
0000105

010001000101090000000100010109

</excerpt>

 It's not the IOR's fault, or, at least, only partially. IIRC, the=20
Java ORBs prior to version 1.4 had trouble handling IORs with embeded
codeset info. It's been a while since I ran into this problem, but I
think omniRB3 uses IIOP1.0 which doesn't have codeset info. omniORB4
'speaks' the newer version of the protocol. The rather brittle ORB
that comes with JRE1.[23].x pretends to understand IIOP1.1 while he
really doesn't and then chokes on the IOR.


 Can you upgrade to another ORB? Else, there might be an option in
omniORB4 to switch back to IIOP1.0, which might help.


 If the above explanation was nonsense, forgive me. I ran into that
problem some time ago, switched ORBs and happily forgot everythig
about it :)



Regards,

	Rainer.



--Apple-Mail-2--349742633--