On 20 January 2017 at 17:29, Rabih M <[email protected]> wrote:
> Hello,
>
> Thank you for you answers.
>
> I am trying to experiment to see if i can do it with the info you gave me.
>
> I took a simple example to start: qdmanage -b <dispatch-machine>:5672 create
> --type=connector role=route-container addr=broker-machine port=5673
> name=rabih.connector
> My goal is to imitate the behavior using JMS and Proton-j.
>
> First, I tried with JMS (attached the code):
> I used an ObjectMessage with JMS_AMQP_TYPED_ENCODING set to true. And I used
> the proton-j encoder to encode the map before sending it.
> But, I am getting a MessageFormatException("Failed to serialize object")
>
> Do you have any idea how can i pass the byte array without failing?
>
I'd be rather surprised if this is actually what you want to do. I'd
expect you to set the map directly on the JMS ObjectMessage, and then
thanks to the special flag the client will encode it itself as an
amqp-value section containing a map (which now that ive kept reading,
matches what you are attempting with proton-j).
>
> Second, I tried with Proton-j (attached code):
> The code i wrote is based on send example in proton-j.
> But the problem is that i am not able to find how to set the destination
> queue of the message. (i used Message.setAddress() but it is wrong)
>
> How can i set a destination queue for the sender or message?
To give the link an addres you need to set the link 'source' and
'target' and use the latter to indicate the address for the sending
link before you open it. E.g for address "queue", the most basic
config would be:
+ Target target = new Target();
+ target.setAddress("queue");
+ snd.setTarget(target );
+ snd.setSource(new Source());
>
> PS. I used wireshark to see the amqp messages that are passing on the
> network and copy the message parameters.
>
>
> Best Regards,
> Rabih
>
> On Wed, Jan 18, 2017 at 2:35 PM, Rob Godfrey <[email protected]>
> wrote:
>>
>> So I think what we said - and I can't find it written down anywhere in the
>> draft, though we reference the JSON spec in the pre-amble, is that any
>> value in the headers or body should be able to be sent in the native AMQP
>> type (and we might need some words there about converting between various
>> numeric types), or as a JSON serialized string. We didn't (to my
>> recollection) talk about whether there should be a way for the requester
>> to
>> be able to influence the form of the reply.
>>
>> Currently the implementation of AMQP Management in the Qpid Broker for
>> Java
>> follows the above conventions (any inbound value can be in the native
>> type,
>> or as a JSON string which can convert to the desired type, however there
>> is
>> no mechanism for controlling the nature of responses).
>>
>> Perhaps this is something we should talk about soon ;-) ?
>>
>> -- Rob
>>
>> On 18 January 2017 at 14:29, Ted Ross <[email protected]> wrote:
>>
>> >
>> >
>> > On 01/18/2017 07:45 AM, Gordon Sim wrote:
>> >
>> >> On 18/01/17 10:45, Rob Godfrey wrote:
>> >>
>> >>> In terms of sending maps/lists I think we said (at OASIS), though it
>> >>> is
>> >>> possibly not yet in the draft spec, that Json formatted equivalents
>> >>> should
>> >>> be able to be used for all values... however I have no idea if the
>> >>> Dispatch
>> >>> Router supports that.
>> >>>
>> >>
>> >> I think that would be very sensible.
>> >>
>> >
>> > Dispatch Router does not support Json formatted bodies at present, but
>> > this is a feature that I would be in favor of putting on the roadmap.
>> >
>> >
>> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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]
>> >
>> >
>
>
>
>
> ---------------------------------------------------------------------
> 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]
