<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=gb18030" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

<br>

<blockquote cite="midE1G7S5j-0006ui-Di@apasphere.com" type="cite">

  <pre wrap="">

This is due to the way codesets are handled in CORBA. It is not a bug in

omniORB. Servers publish the codesets they understand in IORs. Based on

that, clients decide which codesets they can use to communicate with the

server. A corbaloc URI is equivalent to an IOR with no codeset

information in it, so the CORBA spec requires omniORB to treat it as

though the only codeset it supports is ISO 8859-1. </pre>

</blockquote>

even after '_narrow()'? <br>

<blockquote cite="midE1G7S5j-0006ui-Di@apasphere.com" type="cite">

  <pre wrap="">omniORB therefore

tries to convert your UTF-8 string to ISO 8859-1, and fails with a

DATA_CONVERSION exception when it encounters a character it cannot

convert.

I'm afraid you can't use codesets other than ISO 8859-1 with corbaloc

URIs. It's not an omniORB issue but a CORBA specification issue.

  </pre>

</blockquote>

<pre wrap="">

CORBA SPEC :

</pre>

<blockquote>13.6.10.4 corbaloc Server Implementation<br>

The only requirements on an object advertised by a corbaloc URL are

that there must<br>

be a software agent listening on the host and port specified by the

URL. This agent<br>

must be capable of handling GIOP Request and LocateRequest messages

targeted<br>

at the object key specified in the URL.<br>

A normal CORBA server meets these criteria. It is also possible to

implement<br>

lightweight object location forwarding agents that respond to GIOP

Request<br>

messages with Reply messages with a LOCATION_FORWARD status, and respond<br>

to GIOP LocateRequest<br>

</blockquote>

<br>

</body>

</html>