[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

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: 1.5.1, 1.5.2
Fix Version/s: 1.5.3

Type: Bug Priority: Major
Reporter: Brad Hendricks Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1h
Time Spent: Not Specified
Original Estimate: 1h

Attachments: Text File patch.txt    

 Description   

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.



 Comments   
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

Generated at Fri Dec 15 21:36:07 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.