[SWS-385] Exceptions thrown using WS-Addressing result in Assert failure in Addressing10.addAddressingHeaders Created: 24/Jun/08 Updated: 21/Jul/08 Resolved: 02/Jul/08
|Project:||Spring Web Services|
|Affects Version/s:||1.5.1, 1.5.2|
|Reporter:||Brad Hendricks||Assignee:||Arjen Poutsma|
|Time Spent:||Not Specified|
When using WS-Addressing if any interceptor or endpoint throws an Exception the implicit interceptor created by AbstractAddressingEndpointMapping will cause an Assertion failure because it has a null faultAction URI. When this happens no response is sent to the client.
Exposing a faultActionURI to the user in AbstractAddressingEndpointMapping to be used to create the interceptor would fix the problem. If the user is implementing something that uses WS-BaseFaults this would be required anyhow, and the default behavior could be to use the responseAction if the faultAction is not set.
|Comment by Brad Hendricks [ 24/Jun/08 ]|
I have attached a patch that exposes a URI to be used for the faultAction, defaulting to responseAction if not set.
|Comment by Arjen Poutsma [ 02/Jul/08 ]|
I've implemented this, though in a more flexible way than the patch.
The AbstractAddressingEndpointMapping now has a getFaultAction. By default, this returns the same action as the request, with the suffix Fault, but this can be overridden by subclassing or by using the fault() element on the @Action annotation.
|Comment by Arjen Poutsma [ 21/Jul/08 ]|
Closing issues in 1.5.3