On 14 July 2015 at 13:52, plsph <gf...@wp.pl> wrote: > it still gives BytesMessage > probably, the problem is with: > > If the transformer is set to 'jms', the they type of JMS message will depend > on the body type of the AMQP message. > > Body Type JMS Message Type > null Message > Data BytesMessage > AmqpSequence StreamMessage > AmqpValue holding a null Message > AmqpValue holding a String TextMessage > AmqpValue holding a binary BytesMessage > AmqpValue holding a list StreamMessage > AmqpValue ObjectMessage > > so how to craft amqpvalue ? > >
The changes Gordon and I suggested were precisely to make the client send an AmqpValue body containing a string, rather than the alternative it defaults to for non-utf8 content or content not set using 'setContentObject'. Looking back at your earlier messages I noticed something I missed before: > on the broker site, there is setting: > <transportConnector name="amqp" > uri="amqp://0.0.0.0:5672?transport.transformemr=jms"/> You have a typo in your connector config: "transformemr" instead of "transformer". As a result, it is likely not using the 'jms' one at all, but rather the 'native' one, which possibly means you have a warning in your broker log about that. The 'native' transformer makes things a BytesMessage internally within the broker to carry the original AMQP message payload bytes, which should go back out to an AMQP consumer without issue, but would show up to a non-AMQP consumer as a BytesMessage with somewhat odd content. I'm not sure you have actually indicated thus far what particular consumers you are using however. Robbie
