No subject
Fri Aug 31 12:19:44 BST 2012
up some configs, such as nativeCharCodeSet. But with your comment, you
keep saying that the client codeset is affected by server IOR. So, if
client ORB setting and codeset info it get from server IOR are not match,
what will client follow?
Thanks.
Jingdong Sun
InfoSphere Streams Development
Phone 507 253-5958 (T/L 553-5958)
jindong at us.ibm.com
From: Duncan Grisby <duncan at grisby.org>
To: Jingdong Sun/Rochester/IBM at IBMUS,
Cc: omniorb-list <omniorb-list at omniorb-support.com>
Date: 09/18/2012 09:05 AM
Subject: Re: [omniORB] DATA_CONVERSION problem with omniORB 4.1.4
On Fri, 2012-09-14 at 16:52 -0500, Jingdong Sun wrote:
> IOR string as below:
> 14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon
> M[dnameserver.cpp:afterActivation:685] - DN_NAM Service IOR:
> Type ID: IDL:NAM/NameService:1.0
That's not the IOR string. That's a decoded version of it. It's good
enough though.
[...]
> Address: 10.6.24.116:48049
> Location: 10.6.24.116:48049...SP..%%.....
> Key: fe 82 a5 53 50 00 00 25 25 00 00 00 00 00
That is not the object reference that the log shows the client
attempting to use. This shows use of an object set with a corbaloc URI:
omniORB: (0) Creating ref to remote: key<dname>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: (0) Invoke '_is_a' on remote: key<dname>
omniORB: (0) Client attempt to connect to
giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049
The object reference has object key "dname", not the binary thing shown
above, and the endpoint is identified by name rather than the IP address
that's in your IOR. The corbaloc reference was
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname
You need a full IOR, including the codeset information, to be able to
send non-ASCII data.
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
--=_alternative 005B056E86257A7D_=
Content-Type: text/html; charset="US-ASCII"
<font size=2 face="sans-serif">Thanks, Duncan. Based on your comments,
I think I know what the problem is. Will see if my fix going to fix this
and come back to you.</font>
<br>
<br><font size=2 face="sans-serif">One related question:</font>
<br><font size=2 face="sans-serif">From Client side, when we create ORB
object, we also have a chance to set up some configs, such as </font><font size=2 face="Courier New">nativeCharCodeSet</font><font size=2 face="sans-serif">.
But with your comment, you keep saying that the client codeset is affected
by server IOR. So, if client ORB setting and codeset info it get from server
IOR are not match, what will client follow?</font>
<br>
<br><font size=2 face="sans-serif">Thanks.</font>
<br><font size=2 face="sans-serif">Jingdong Sun<br>
InfoSphere Streams Development<br>
Phone 507 253-5958 (T/L 553-5958) <br>
jindong at us.ibm.com</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Duncan Grisby <duncan at grisby.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Jingdong Sun/Rochester/IBM at IBMUS,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">omniorb-list <omniorb-list at omniorb-support.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/18/2012 09:05 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [omniORB]
DATA_CONVERSION problem with omniORB 4.1.4</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Fri, 2012-09-14 at 16:52 -0500, Jingdong Sun wrote:<br>
<br>
> IOR string as below: <br>
> 14 Sep 2012 17:45:38.403 [9509] INFO :::NAM.StartupDaemon<br>
> M[dnameserver.cpp:afterActivation:685] - DN_NAM Service IOR:
<br>
> Type ID: IDL:NAM/NameService:1.0 <br>
<br>
That's not the IOR string. That's a decoded version of it. It's good<br>
enough though.<br>
<br>
[...]<br>
> Address: 10.6.24.116:48049 <br>
> Location: 10.6.24.116:48049...SP..%%..... <br>
> Key: fe 82 a5 53 50 00 00 25 25
00 00 00 00 00 <br>
<br>
That is not the object reference that the log shows the client<br>
attempting to use. This shows use of an object set with a corbaloc URI:<br>
<br>
omniORB: (0) Creating ref to remote: key<dname><br>
target id : IDL:omg.org/CORBA/Object:1.0<br>
most derived id: <br>
omniORB: (0) Invoke '_is_a' on remote: key<dname><br>
omniORB: (0) Client attempt to connect to giop:tcp:d0701b06.pok.hpc-ng.ibm.com:48049<br>
<br>
The object reference has object key "dname", not the binary thing
shown<br>
above, and the endpoint is identified by name rather than the IP address<br>
that's in your IOR. The corbaloc reference was<br>
corbaloc::d0701b06.pok.hpc-ng.ibm.com:48049/dname<br>
<br>
You need a full IOR, including the codeset information, to be able to<br>
send non-ASCII data.<br>
<br>
Duncan.<br>
<br>
-- <br>
-- Duncan Grisby --<br>
-- duncan at grisby.org --<br>
-- </font></tt><a href=http://www.grisby.org/><tt><font size=2>http://www.grisby.org</font></tt></a><tt><font size=2>
--<br>
<br>
<br>
</font></tt>
<br>
--=_alternative 005B056E86257A7D_=--
More information about the omniORB-list
mailing list