How can I specify an error-channel after a hand-off to an async Task-Executor.

[Olivier Quirion]

Here is my case:

At some point in my main flow I Wire-Tap my message for asynchronous monitoring/logging.

...
 <int:wire-tap channel="dispatchRequestChannel" pattern="externalRequestChannel" />
...
 <int:channel id="dispatchRequestChannel">
 	<int:dispatcher task-executor="asynchronousExecutor"/>
 </int:channel>
...
<int:chain input-channel="dispatchRequestChannel">
	<int:header-enricher>
		<int:error-channel value="logErrorChannel"/>
	</int:header-enricher>
	<int:filter expression="headers.get('serviceId') == 'TimerDispositionForLot'"/>
	<int:service-activator ref="messageHandler" method="extractRequest" />
	<int:service-activator ref="monitoringService" method="monitorRequest"/>
</int:chain>
...
 <int:channel id="logErrorChannel"/>
<int:logging-channel-adapter channel="logErrorChannel" level="DEBUG" auto-startup="true" log-full-message="true" />

When I inspect the header at the messageHandler-->extractRequest point in time , the reply-channel is still the same as the error-channel. This is because of the direct nature of this flow the error-channel is bounded to the caller's thread, or something like this...
I would have thought the "header-enricher" would have permit me to define a error-channel anyhow?
By the way, i'm using s-i version 2.1.2.

[Gary Russell]

Add overwrite="true" to the header (error-channel) element (or default-overwite="true" on the header-enricher element).

By default, existing headers are not overwritten.

[Olivier Quirion]

Thanks Gary, this worked fine. I didn't try it at first because my IDE (Rational Software Development [Eclipse base]) suggested the default value was true.

Attachment 5052

I look over the .xsd file but it doesn't seem to come from there.
Thanks anyhow.

[Gary Russell]

Interesting; that seems to be a side-effect of delcaring the type thus:

			<xsd:simpleType>
				<xsd:union memberTypes="xsd:boolean xsd:string" />
			</xsd:simpleType>

The IDE (in my opinion) is incorrectly taking the first value of the boolean enumeration as the "default".

I just tried adding a new attribute, which confirmed this.

We should probably set an explicit default="false" to avoid this misleading eclipse behavior, or at least mention the default in the schema documentation. Feel free to open up a 'Documentation' JIRA.