[omniORB] Character codeset negotiation seems to fail with a Jacorb server
Duncan Grisby
duncan at grisby.org
Fri Apr 28 12:41:20 BST 2017
On Thu, 2017-04-27 at 18:02 +0000, Lewis, James via omniORB-list wrote:
> [12:36:43] omniORB: (?) 2017-04-27 12:36:43.526000: Creating ref to
> remote: key<Supplier>
> target id : IDL:omg.org/CORBA/Object:1.0
> most derived id:
Where did this object reference for the "Supplier" object come from?
Is it from a corbaloc URI? I suspect that it is...
[...]
> [12:36:43] omniORB: (?) 2017-04-27 12:36:43.597000: Invoke 'connect'
> on remote: key<Supplier>
>
> [12:36:43] omniORB: (?) 2017-04-27 12:36:43.597000: throw BAD_PARAM
> from cs-UTF-16.cc:138 (NO,BAD_PARAM_WCharTCSNotKnown)
It does not know the WChar transmission code set to use. Code sets are
embedded in IORs, but I think you probably used a corbaloc URI rather
than an IOR. omniORB therefore does not know what codesets the server
supports, so it complains.
The official, standard, way to handle that is to use the initial
corbaloc reference to retrieve a full object reference IOR. That way
the omniORB client will get the codeset information from the JacORB
IOR.
The other thing you can do is get the latest 4.2.x development
snapshot. That has new options -ORBdefaultCharCodeSet and
-ORBdefaultWCharCodeSet that allow you to violate the CORBA standard
and use default codesets for corbaloc URIs and any other object
reference that is missing codeset information. Get the snapshot from
http://omniorb.sourceforge.net/snapshots/omniORBpy-4.2-latest.tar.gz
Or get the 4_2 branch from svn.
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list