Jamo, I also had a similar concern. I would have liked the faults to be more user friendly, with the offending field clearly outlined.
-Vladimir On 3/17/15, 4:17 PM, "jamo" <[email protected]> wrote: >CXF soap faults for unmarshalling errors do not contain information >useful in >locating the error. How can I improve the soap fault's faultString, so >that >it contains more useful info? It's unclear whether an interceptor or >other >component will be able to improve this content. > >For example, suppose we have a WSDL input message containing element of >type >xsd:dateTime. When we pass an invalid content, "xxxx", the faultString >contains: >Unmarshalling Error: xxxx . > >The full stack trace contains messages with location of the bad string, >i.e. >: > [com.sun.istack.SAXParseException2; lineNumber: 5; columnNumber: 38; >xxxx]. > >However, the fault only displays the message from the original failure, >in >this case, [java.lang.IllegalArgumentException: xxxx]. > >The problems is in this fragment in JAXBEncodeDecoder, which extracts the >message from the linked exception, i.e., the last exception in the stack: > } catch (PrivilegedActionException e) { > Exception ex = e.getException(); > if (ex instanceof Fault) { > throw (Fault)ex; > } > if (ex instanceof javax.xml.bind.UnmarshalException) { > javax.xml.bind.UnmarshalException unmarshalEx = >(javax.xml.bind.UnmarshalException)ex; > if (unmarshalEx.getLinkedException() != null) { > throw new Fault(new Message("UNMARSHAL_ERROR", LOG, > >unmarshalEx.getLinkedException().getMessage()), ex); > > > > >-- >View this message in context: >http://cxf.547215.n5.nabble.com/Unmarshalling-error-content-usability-tp57 >55169.html >Sent from the cxf-user mailing list archive at Nabble.com.
