I have cheated slightly and set the fault To EPR on my message with the first action
This is the cause of your problem. The ReplyTo/FaultTo settings are the responsibility of the caller to your service and therefore your action has no impact on these.
Take a look at the gateway composers, for example PackageJmsMessageContents, and try setting one on your gateway to initialise the FaultTo address. You can specify the composer class by including a composer-class property in your gateway definition.
BTW, this has been made much more explicit in the latest documentation.
Thanks for your quick responses.
I am using the 4.2.1GA version of the jbossesb server.
I have managed to get the Fault To part of the message set, and the response is indeed sent to that queue when I send an ActionProcessingFaultException.
I appear to have missed the Documentation about this Exception as well, but having read the subversion source code I thought I should be able to access the original ESB message (including all headers, such as correlation ID and original reply queue) in my new message queue, but it appears that the message that i get into the Error Processing service (which should return the fault message to the correct JMS reply queue with a correlation ID) does not have the Header information.
Please let me know if you think this is the correct behaviour as this will lead to some interesting problems when trying to implement the JMS request/reply pattern.
The correct way to implement the request/reply pattern is to include the information you need in the FaultTo EPR. If you take a look at the following example if should give you some ideas.
Could you tell me why this example doesn't work on 4.2.1GA? Is it to do with the way the wiretap works or is it deeper in the source code of the esb Message/Pipeline processing?
I have set the extension information on the message on my in queue async action. This appears to work if I get the information out during that pipeline of actions, but when I get to the wiretap and the message is passed to my synchronous action the extension information on the message is no longer set.
I was wondering if it was a case of it being a problem with one of the actions (in which case i could copy it into my ESB folder from the trunk and use a local version until I can get the server upgraded) or if it was somethign deeper, meaning this strategy of request and repsonse was of no use in 4.2.1GA.
Is there a bug report/ticket for the problem so I could have a look what needs to change.
IIRC there were a couple of issues within the pipeline/fault handling and JBESB-1395 is definitely one of them.