Use the Message:setContentObject()/getContentObject() methods and
supply the body as a qpid::types::Variant which lets you specify the
*encoding* as utf8, ensuring it is encoded correctly as a string for
AMQP 1.0 rather than bytes.
e.g. either:
qpid::types::Variant value(s[i], "utf8");
msg.setContentObject(value);
or:
msg.getContentObject() = s[i];
msg.getContentObject().setEncoding("utf8");
On Fri, Jul 2, 2021 at 12:18 PM [email protected]
<[email protected]> wrote:
>
> Many thanks for your responses. Using the single quote helped me to get this
> working.
>
> Now I am trying to add a request to a queue. For this I create a sender and
> receiver where I would send the request on 'queue://ID.RequestQueueExample'
> and then receive any response from 'queue://ID.ResponseQueueExample'.
> Sender sender = session.createSender("'queue://ID.RequestQueueExample'");
> Receiver recv = session.createReceiver("'queue://ID.ResponseQueueExample'");
>
> Then I create a Message and set the necessary parameters and prepare the
> Content as required. The content needs to be in XML format which I populate
> beforehand, extract it in a string and then invoke Message::setContent(str).
> I also tried setting the contentType to "utf8". Not sure if we need to set
> this to any other type?
> Here is an example of the string passed to Message::setContent(str) -
> <ExampleRequestMsg>
> <Header>
> <field1>ABCDE</field1>
> <field2>AB_CDE</field2>
> </Header>
> <Body>
> <field1>XYZ</field1>
> </Body>
> </ExampleRequestMsg>
>
> However, when I send the request, I receive back error from the broker in the
> receiver queue complaining that the message format is incorrect. My suspicion
> are -
>
> 1) The content and contentType is not being set properly.
> 2) I do not find the sender queue details in the outgoing AMQP frames. In
> the message, I set the Message::ReplyTo with the Receiver Queue Address.
> After looking at some example AMPQ frames which seems to be taken from JMS, I
> see that the outgoing frame also has the Sender queue address
> 'queue://ID.ReqQueueExample' in the outgoing frame. I am not quite sure how
> can I add that with the C++ QPID API. The Message class do not seem to have
> that option.
>
> Any suggestions for the above 2 points would be highly appreciated.
>
> Best Regards,
> Rahul
> -----Original Message-----
> From: Robbie Gemmell <[email protected]>
> Sent: 01 July 2021 15:01
> To: users <[email protected]>
> Subject: Re: QPID C++ Subscribing to a topic
>
> On Thu, 1 Jul 2021 at 13:18, Gordon Sim <[email protected]> wrote:
> >
> > On Thu, Jul 1, 2021 at 1:08 PM [email protected]
> > <[email protected]> wrote:
> > > 1. As per Robbie's suggestion, I have tried adding topic:// in the
> > > past as well but the address and name selection gets chopped off from our
> > > end (after topic: ) in the outgoing AMQP frame to Broker.
> > >
> > > Our Code -
> > > qpid::messaging::Receiver topic_receiver =
> > > session.createReceiver("topic://ID.ExampleTopic; {node:{type:topic}}"
> > > ");
> >
> > You need some ugly quoting in there, netsed single quotes around the
> > address, e.g.:
> >
> > session.createReceiver("'topic://ID.ExampleTopic';
> > {node:{type:topic}}");
> >
> > That prevents the '/' being misinterpreted. (It has special meaning in
> > the qpid::messaging address syntax, which we don't want here).
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected] For
> > additional commands, e-mail: [email protected]
> >
>
> What Gordon said with the quoting should work to get it to parse correctly, I
> forgot about that being needed (as its not a combination I've really used
> myself).
>
> Note I wasnt suggesting you do both the prefix and the 'type:topic'
> node config though, as I dont think ActiveMQ 5 actually looks for the
> terminus 'topic' capability that adds, rather it uses the address name and
> looks for a name prefix of "topic://" (something which e.g the JMS client
> adds itself under the covers based on values the broker advertises at
> connection open time).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For additional
> commands, e-mail: [email protected]
>
>
> --------------------------------------------------------------------------------
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
> or views contained herein are not intended to be, and do not constitute,
> advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform
> and Consumer Protection Act. If you have received this communication in
> error, please destroy all electronic and paper copies and notify the sender
> immediately. Mistransmission is not intended to waive confidentiality or
> privilege. Morgan Stanley reserves the right, to the extent permitted under
> applicable law, to monitor electronic communications. This message is subject
> to terms available at the following link:
> http://www.morganstanley.com/disclaimers If you cannot access these links,
> please notify us by reply message and we will send the contents to you. By
> communicating with Morgan Stanley you consent to the foregoing and to the
> voice recording of conversations with personnel of Morgan Stanley.
>
> You may have certain rights regarding the information that Morgan Stanley
> collects about you. Please see our Privacy Pledge
> https://www.morganstanley.com/privacy-pledge for more information about your
> rights.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
