[jira] [Commented] (PROTON-1288) c++ provide access to message maps as proton::value

["Kim van der Riet (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491375#comment-15491375 ] 

Kim van der Riet commented on PROTON-1288:
------------------------------------------

A recent JMS message test over Dispatch router (which at this time does not handle message annotations) failed because:
1. the annotations were missing on the received message;
2. the JMS receiver code did not anticipate this possibility, and the resulting exception was caught only at an outer try/catch.
The exception message was simply {{"no more data"}}. Perhaps it would be useful for the accessors of properties and annotations to send {{"key not found"}} or something similar as an exception message. Even better: {{"key \"" << key << "\" not found"}}.

> c++ provide access to message maps as proton::value
> ---------------------------------------------------
>
>                 Key: PROTON-1288
>                 URL: https://issues.apache.org/jira/browse/PROTON-1288
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: cpp-binding
>    Affects Versions: 0.14.0
>            Reporter: Alan Conway
>            Assignee: Alan Conway
>             Fix For: 0.15.0
>
>
> We need to provide access to the message property maps as a proton::value. 
> Given
> {code}
>     std::map<string, scalar> my_map;
>     proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
>    proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
>    proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
>    proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want a convenient cached map vs. you want to decode to your own C++ map, work on it, and possibly re-encode it later. I lean towards 3. but open to persuasion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org