[jira] Resolved: (AMQCPP-77) Inconsistency when getting string property between Stomp and Openwire

["Timothy Bish (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/activemq/browse/AMQCPP-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish resolved AMQCPP-77.
--------------------------------

    Resolution: Fixed

Fixed in trunk, the Stomp Messages now throw a NoSuchElementException for any access to a property that isn't set.  This is now consistent with the behavior of the OpenWire commands.

This changes implies that current users of Stomp must now check that the properties all exist before attempting to access them, or handle the NoSuchElementException.

> Inconsistency when getting string property between Stomp and Openwire
> ---------------------------------------------------------------------
>
>                 Key: AMQCPP-77
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-77
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Openwire
>    Affects Versions: 2.0
>            Reporter: Albert Strasheim
>         Assigned To: Timothy Bish
>             Fix For: 2.0
>
>
> In our current code we call getStringProperty on a BytesMessage for a property that might not exist. When running with Stomp, this returns an empty string. When running with Openwire, a NoSuchElementException is thrown.
> We could easily change our code to first check whether the property exists with propertyExists prior to getting it, but Stomp and Openwire should probably handle missing string properties in the same way.
> I think this default empty string value was added at some point to avoid null pointers elsewhere in the code. Refer to AMQCPP-43.

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