[jira] Updated: (QPID-119) Add implementation for MapMessage

["Marnie McCormack (JIRA)" <qp...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/QPID-119?page=all ]

Marnie McCormack updated QPID-119:
----------------------------------

    Component/s: Java Client
                     (was: C++ Client)

> Add implementation for MapMessage
> ---------------------------------
>
>                 Key: QPID-119
>                 URL: http://issues.apache.org/jira/browse/QPID-119
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M1
>            Reporter: Marnie McCormack
>         Assigned To: Martin Ritchie
>             Fix For: M2
>
>
> Currently the Java codebase looks like it might support MapMessage, but in reality it is not implemented under the covers.
> So, the method AMQSession.createMapMessage will always (currently) return an AMQException.
> Need to implement the MessageFactoryRegistry.createMessage("jms/map-message") method as per JMS spec:
> 3.11 JMS Message Body
> JMS provides five forms of message body. Each form is defined by a message
> interface: <snip>
> ? MapMessage - a message whose body contains a set of name-value pairs where names are Strings and values are Java primitive types. The entries can be accessed sequentially by enumerator or randomly by name. The order of the entries is undefined.
> AND ....
> 3.11.3 Conversions Provided by StreamMessage and MapMessage
> Both StreamMessage and MapMessage support the same set of primitive data types. The types can be read or written explicitly using methods for each type. They may also be read or written generically as objects. For instance, a call to MapMessage.setInt("foo", 6) is equivalent to MapMessage.setObject("foo", new Integer(6)). Both forms are provided because the explicit form is convenient for static programming and the object form is needed when types are not known at compile time.
> Both StreamMessage and MapMessage support the following conversion table. The marked cases must be supported. The unmarked cases must throw a JMS MessageFormatException. 
> The String to numeric conversions must throw a java.lang.NumberFormatException if the numeric's valueOf() method does not accept the String value as a valid representation. 
> StreamMessage and MapMessage must implement the String to boolean conversion as specified by the valueOf(String) method of Boolean as defined by the Java language. Attempting to read a null value as a Java primitive type must be treated as calling the primitive's corresponding valueOf(String) conversion method with a null value. 
> Since char does not support a String conversion, attempting to read a null value as a char must throw NullPointerException.
> Getting a MapMessage field for a field name that has not been set is handled as if the field exists with a null value.
> If a read method of StreamMessage or BytesMessage throws a MessageFormatException or NumberFormatException, the current position of the read pointer must not be incremented. 
> A subsequent read must be capable of recovering from the exception by rereading the data as a different type.
> (see spec for more detail/table)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira