keeping default headers in amqp outbound channel adapters

[nettad]

I am using the mapped-request-headers to send a new header. The problem is, using it makes me loose all the default headers that get sent. I want to add a new header to the list of default headers. How do I do that?

This is what I have:

<int:gateway id="messageGateway" default-request-channel="requestChannel"
		service-interface="HelloService" default-reply-timeout="10000">
		<int:method name="sayHello">
			<int:header name="requestType" value="hello" />
		</int:method>
	</int:gateway>
<int-amqp:outbound-channel-adapter
		id="outbound" channel="requestChannel" exchange-name="si.test.exchange" routing-key="si.test.queue"
		amqp-template="amqpTemplate"  mapped-request-headers="requestType"/>

On the other side I am able to retrieve the requestType header but I'm missing the other headers, in particular the replyChannel. So my question again, is it possible to add requestType to the list of headers without overriding them altogether?

Thanks

[Gary Russell]

There is no override effect - the standard amqp headers are copied plus your specified headers.

You cannot propagate the replyChannel over AMQP - it is a live java object where some thread is waiting in receive() to receive a reply.

What do you want to do with the replyChannel on the other system?

[nettad]

There is no override effect - the standard amqp headers are copied plus your specified headers.

You cannot propagate the replyChannel over AMQP - it is a live java object where some thread is waiting in receive() to receive a reply.

What do you want to do with the replyChannel on the other system?

I don't want to do anything with the replyChannel per say. I was debugging, trying to figure out why I wasn't getting a response for the message I sent. I configured a gateway and an amqb outbound channel adapter on one end and I was expecting to receive a response generated by the other end. What I was seeing was no response and the message was still in the queue. So I started debugging and found out there was some swallowed exception "The replyTo header must not be null on a request Message being handled by the AMQP inbound gateway." I looked at the message headers and I noticed that header wasn't there. I removed the mapped-request-headers="requestType" attribute and the exception stopped happening. I noticed that the message now had a few headers that I wasn't seeing before.

The message header without mapped-request-header:

[Headers={timestamp=1335294252037, 
id=7748e09a-fea6-41a2-acc3-57524edb8e28,
errorChannel=org.springframework.integration.core.MessagingTemplate$TemporaryReplyChannel@6184d88,
amqp_receivedRoutingKey=si.test.queue, 
amqp_deliveryMode=PERSISTENT,
replyChannel=org.springframework.integration.core.MessagingTemplate$TemporaryReplyChannel@6184d88, 
amqp_contentType=text/plain, amqp_contentEncoding=UTF-8, amqp_deliveryTag=1, amqp_redelivered=false}]

with the mapped-request-headers I was only seeing:

[Headers={requestType=hello}

This is what brought me to the conclusion that the default headers were somehow being replaced. If that's not the case, please tell me what I'm doing wrong.

Just for reference, the other side looks like this (omitting the channel defs):

<int-amqp:inbound-gateway id="inboundGateway"
		request-channel="requestChannel" connection-factory="connectionFactory"
		queue-names="si.test.queue" reply-channel="replayChannel"
		error-channel="errorChannel" mapped-request-headers="requestType" />

<int:header-value-router id="headerRouter"
		header-name="requestType" input-channel="requestChannel">
		<int:mapping value="hello" channel="helloServiceChannel" />
		<int:mapping value="goodbye" channel="goodbyeServiceChannel" />
	</int:header-value-router>

	<int:service-activator input-channel="helloServiceChannel"
		ref="helloService" method="hello" />

	<int:service-activator input-channel="goodbyeServiceChannel"
		ref="goodbyeService" method="goodbye" />

Thanks again.

[Gary Russell]

I didn't fully look at your config; I was answering your question about header mapping.

You will never get a reply to your gateway because you are sending the request out on a channel adapter - which are for one-way integration - there is no reply from an outbound-adapter. You need an outbound gateway.

However, outbound gateways use a temporary AMQP reply queue; if you need a specific reply queue, you will need to wait for AMQP 1.0.1. Otherwise you can use adapters but you need to use some advanced techniques for preserving the replyChannel.

[nettad]

I didn't fully look at your config; I was answering your question about header mapping.

You will never get a reply to your gateway because you are sending the request out on a channel adapter - which are for one-way integration - there is no reply from an outbound-adapter. You need an outbound gateway.

However, outbound gateways use a temporary AMQP reply queue; if you need a specific reply queue, you will need to wait for AMQP 1.0.1. Otherwise you can use adapters but you need to use some advanced techniques for preserving the replyChannel.

Honest mistake :-). I changed the adapter to a gateway. Now what I'm seeing is a different exception: "no channel resolved by router..." I'm assuming the problem is that the header isn't being transfered. I have the mapped-request-header set on all the amqp gateways (as you can see by the code examples in my previous post). I verified the spelling so I'm sure that's ok. Any suggestions?

Thanks.

[Gary Russell]

If you look in the debug log (both sides), you should see messages like...

headerName=[baz] WILL NOT be mapped 
headerName=[foo] WILL be mapped, matched pattern=foo

...as well as the messages themselves (including the headers).

[nettad]

If you look in the debug log (both sides), you should see messages like...

headerName=[baz] WILL NOT be mapped 
headerName=[foo] WILL be mapped, matched pattern=foo

...as well as the messages themselves (including the headers).

Thanks..turns out I was using mapped-reply instead of mapped-request. The debugging was really helpful. Thanks for pointing it out.