Exceptions thrown using WS-Addressing result in Assert failure in Addressing10.addAddressingHeaders [SWS-385]

[gregturn]

Brad Hendricks opened SWS-385 and commented

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.

---

Affects: 1.5.1, 1.5.2

Attachments:

• patch.txt (2.50 kB)

Referenced from: commits 4b765c4

[gregturn]

Brad Hendricks commented

I have attached a patch that exposes a URI to be used for the faultAction, defaulting to responseAction if not set.

[gregturn]

Arjen Poutsma commented

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.

[gregturn]

Arjen Poutsma commented

Closing issues in 1.5.3