This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Naming Convention based Soap Fault elements

Jan 27th, 2012, 05:02 PM

Hello All,

Using Spring WS 2.0.1 I'm trying to define the soap faults a given operation can return within the wsdl. I'm using the dynamically generated wsdl functionality of Spring WS and I found that I can associate fault elements to operations by following the naming convention [operationName]Fault. This works beautifully and the generated wsdl correctly lists my Fault element with the operation:

I've created a custom version of SoapFaultMappingExceptionResolver in order to customize the generated soap fault but for some reason, the SoapFault argument that gets passed into the customizeFault method doesn't have it's detail attribute populated with an instance of the Fault that was described in the WSDL. From all the research I've done so far, it seem that you're 100% on you own to create the FaultDetail object that is described in the wsdl. If you don't have a one to one mapping between the exception thrown and the declared fault, there's not an *easy* way within the body of that method to figure out which fault detail element should be created. You *do* get access to the endpoint itself so I'm sure you could somehow use that to figure out which operation was called but that seems like a bad approach. Is there something that I'm missing or is this a bit of a gap in Spring WSs handling of SoapFaults? I've scoured through a bunch of posts regarding Spring WS and SoapFaults but I'm yet to find anything addressing this scenerio. Any insight would be greatly appreciated.
Thanks in advance