Codesets negotiation error between JacORB and omniORB

Development C++
1

Hi tangoer:

using jive to set string_scalar attribute of TangoTest device with a string containing multi-bytes characters, like “hello😄”, the following error occurs in jive: org.omg.CORBA.DATA_CONVERSION: server side exception: null.

I think this is caused by the codeset negotiation between JacORB and omniORB, but I cannot find a way to set the codeset in jive.

Environment:

  • omniORB 4.3.2
  • libzmq-4.3.5 (cppzmq-4.10.0)
  • tango-10.0.2 (installed from tango-10.0.2.tar.gz)

https://omniorb.net/omni43/omniORB/omniORB009.html: For the ORB to know how to handle strings and wstrings given to it by the application, it must know what code set they are represented with, so it can properly translate them if need be. The defaults are ISO 8859-1 (Latin 1) for char and string, and UTF-16 for wchar and wstring. Different code sets can be chosen at initialisation time with the nativeCharCodeSet and nativeWCharCodeSet parameters. The supported code sets are printed out at initialisation time if the ORB traceLevel is 15 or greater.

https://www.jacorb.org/releases/3.9/ProgrammingGuide.pdf : 3.2.3 Codesets. JacORB implements codeset negotiation through org.jacorb.orb.giop.CodeSet. Codesets that are currently supported are

  • ISO8859_1
  • ISO8859_15
  • UTF8
  • UTF16
  • UCS2
2

Hi @sliu ,
What we do in our institute is that we have a file named /etc/omniORB.cfg (default omniORB file location on Linux) with the following content on our hosts with the following content:

nativeCharCodeSet=UTF-8

On Win32 platforms (Windows NT, 2000, 95, 98), omniORB first checks the environment variable OMNIORB_CONFIG to obtain the pathname of the configuration file. If this is not set, it then attempts to obtain configuration data in the system registry. It searches for the data under the key HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.

This file tells omniORB, which is used in our C++ and python device servers and clients to use UTF-8 instead of the default omniORB latin 1.

The example you were mentioning seems to work fine in our institute when using UTF-8.

Hoping this helps,
Reynald

3

Thanks a lot, it works for me.