activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] Resolved: (AMQCPP-261) Handle Multibyte Strings or Strings encoded in Charsets other than US-ASCII
Date Fri, 12 Mar 2010 21:51:44 GMT


Timothy Bish resolved AMQCPP-261.

    Resolution: Fixed

Removed all string encoding and decoding from Message processing.

Added class MarshallingSupport to activemq/util with methods that encode and decode strings
to modified UTF-8 for those that want to send string data with values between [0...255] but
don't want to use a third party lib.

Users must now encode and decode wide char string as UTF-8 or modified UTF-8 to share string
data with a Java or .NET client app.

> Handle Multibyte Strings or Strings encoded in Charsets other than US-ASCII
> ---------------------------------------------------------------------------
>                 Key: AMQCPP-261
>                 URL:
>             Project: ActiveMQ C++ Client
>          Issue Type: Improvement
>          Components: CMS Impl, Decaf, Openwire
>    Affects Versions: 3.0.1
>            Reporter: Timothy Bish
>            Assignee: Timothy Bish
>             Fix For: 3.2.0
> The CMS API defines the interface for Strings in the TextMessage using the C++ std::string
and const char* primitives and doesn't consider character encodings in its interface or the
use of multibyte string representations.  
> In order to allow the use of Strings between Java and C++ and .NET clients the strings
in the TextMessage as well as those in MapMessage, StreamMessage, and BytesMessage (when wreiteUTF
and readUTF are called) as well as message properties of the string type are encoded in the
JAVA standard Modified UTF-8 format for serialized strings.  This design makes the assumption
that strings passed are in US-ASCII format and that the strings from the broker are also encoded
with no char values greater than 255 and throws an exception if one is encountered.  
> The CMS interface needs to be extended to allow for more flexible string handling and
offer a mechanism to deal with string encodings other than ASCII. 
> Another alternative is to change the assumption about strings in the CMS API to assume
that all string are given as either ASCII strings with chars < 127 and no embedded nulls
or are already encoded by the user as Modified UTF-8 by the user so that a Java or .NET client
can read all strings sent in CMS Messages as well.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message