You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Milan Doshi <mi...@gmail.com> on 2008/10/14 03:49:33 UTC
Re: Handling internal errors via SOAP faults
We have defined a :
1. User Defined Exception.
2. There is a Fault element defined in WSDL.
3. The WSDL2Java geneartes a valid anotations.
HOWEVER, when we send back a Fault to the client, it is ONLY a SOAPFault
with errorMessage. No DETAIL ELEMENT is present...:(. hence our user
specific info is completely missing!!!
Can you please guide ?
We are using :
Document / Literal.
CXF2.1.2
JDK1.5_16
Any help appreciated!
Thanks,
Milan
dkulp wrote:
>
> On Friday 07 March 2008, David Castañeda wrote:
>> Glen, I have been fighting against this sort of questions from several
>> weeks now,
>>
>> I start a sample project that is on Jira about correct handling,
>> unfortunately I haven't found an answer from someone who know, neither
>> I have found the way to produce correct code for server, client
>> faults.
>>
>> Anyway my idea, is to only expose the exception that can be handled by
>> the client, like InvalidCountryNameFault or
>> MaxRequestQuantityOverLimit, mark these as Client Fault, and any other
>> exception like (RuntimeException), DBNotAvailable, etc (things client
>> can't handle, ServiceException) as a general exception marked as
>> Server Fault, but as I said, I haven't found the way to do this.
>
> That's probably because the spec specifically does not allow for them.
> I've looked at the sample in the JIRA and there will be no way to do it,
> per spec. Basically, undeclared exceptions are all to be treated as
> generic runtime exceptions and mapped, per spec, to a relatively
> generice soap:fault on the wire and then to a SOAPFaultException on the
> client side. If you want properly typed exceptions, you HAVE to put
> them on the SEI interface methods.
>
> Using some JAX-WS/JAXB "tricks", you can control the on-the-wire
> representation of the exception a little more, but that won't stop it
> from being mapped to a generic SOAPFaultException on the client side.
>
> For example, if we take your sample from CXF-1434 and change the
> UncheckedWrongTextException to look like:
>
> @WebFault(name = "UncheckedWrongTextException")
> public class UncheckedWrongTextException extends RuntimeException {
> UncheckedWrongText i;
> public UncheckedWrongTextException(String msg) {
> super(msg);
> i = new UncheckedWrongText();
> i.setMessage(msg);
> }
> public UncheckedWrongTextException(String msg, int t) {
> super(msg);
> i = new UncheckedWrongText();
> i.setMessage(msg);
> i.setIdx(t);
> }
> public UncheckedWrongText getFaultInfo() {
> return i;
> }
>
> @XmlRootElement
> public static class UncheckedWrongText {
> int idx;
> String msg;
> public int getIdx() {
> return idx;
> }
> public void setIdx(int i) {
> idx = i;
> }
> public void setMessage(String m) {
> msg = m;
> }
> public String getMessage() {
> return msg;
> }
>
> }
> }
>
> And then add to HelloWorld.java:
> @XmlSeeAlso({UncheckedWrongTextException.UncheckedWrongText.class})
>
> Then the on-the-wire fault would look like:
>
>
>
> soap:Server
> Only characters are allowed
>
>
> 0
> Only characters are allowed
>
>
>
>
>
>
>
> However, the client will still only get a SOAPFaultException. In this
> case, though, the SOAPFaultException will have a getDetail() element
> that contains the detail. Thus, it IS more information to the user.
>
>
> ---
> J. Daniel Kulp
> Principal Engineer, IONA
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Handling-internal-errors-via-SOAP-faults-tp15892864p19965827.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Handling internal errors via SOAP faults
Posted by Glen Mazza <gl...@gmail.com>.
My example here: http://www.jroller.com/gmazza/date/20080308#MTstep10 does
display error details.
HTH,
Glen
Milan Doshi wrote:
>
> We have defined a :
> <br>
> 1. User Defined Exception.<br>
> 2. There is a Fault element defined in WSDL.<br>
> 3. The WSDL2Java geneartes a valid anotations.<br>
>
> HOWEVER, when we send back a Fault to the client, it is ONLY a SOAPFault
> with errorMessage. No DETAIL ELEMENT is present...:(. hence our user
> specific info is completely missing!!!
> <br><br>
> Can you please guide ?<br>
> <br>
> We are using :<br>
> Document / Literal.<br>
> CXF2.1.2<br>
> JDK1.5_16<br>
> <br><br>
> Any help appreciated!<br>
>
> Thanks,<br>
> Milan
>
>
>
>
> dkulp wrote:
>>
>> On Friday 07 March 2008, David Castañeda wrote:
>>> Glen, I have been fighting against this sort of questions from several
>>> weeks now,
>>>
>>> I start a sample project that is on Jira about correct handling,
>>> unfortunately I haven't found an answer from someone who know, neither
>>> I have found the way to produce correct code for server, client
>>> faults.
>>>
>>> Anyway my idea, is to only expose the exception that can be handled by
>>> the client, like InvalidCountryNameFault or
>>> MaxRequestQuantityOverLimit, mark these as Client Fault, and any other
>>> exception like (RuntimeException), DBNotAvailable, etc (things client
>>> can't handle, ServiceException) as a general exception marked as
>>> Server Fault, but as I said, I haven't found the way to do this.
>>
>> That's probably because the spec specifically does not allow for them.
>> I've looked at the sample in the JIRA and there will be no way to do it,
>> per spec. Basically, undeclared exceptions are all to be treated as
>> generic runtime exceptions and mapped, per spec, to a relatively
>> generice soap:fault on the wire and then to a SOAPFaultException on the
>> client side. If you want properly typed exceptions, you HAVE to put
>> them on the SEI interface methods.
>>
>> Using some JAX-WS/JAXB "tricks", you can control the on-the-wire
>> representation of the exception a little more, but that won't stop it
>> from being mapped to a generic SOAPFaultException on the client side.
>>
>> For example, if we take your sample from CXF-1434 and change the
>> UncheckedWrongTextException to look like:
>>
>> @WebFault(name = "UncheckedWrongTextException")
>> public class UncheckedWrongTextException extends RuntimeException {
>> UncheckedWrongText i;
>> public UncheckedWrongTextException(String msg) {
>> super(msg);
>> i = new UncheckedWrongText();
>> i.setMessage(msg);
>> }
>> public UncheckedWrongTextException(String msg, int t) {
>> super(msg);
>> i = new UncheckedWrongText();
>> i.setMessage(msg);
>> i.setIdx(t);
>> }
>> public UncheckedWrongText getFaultInfo() {
>> return i;
>> }
>>
>> @XmlRootElement
>> public static class UncheckedWrongText {
>> int idx;
>> String msg;
>> public int getIdx() {
>> return idx;
>> }
>> public void setIdx(int i) {
>> idx = i;
>> }
>> public void setMessage(String m) {
>> msg = m;
>> }
>> public String getMessage() {
>> return msg;
>> }
>>
>> }
>> }
>>
>> And then add to HelloWorld.java:
>> @XmlSeeAlso({UncheckedWrongTextException.UncheckedWrongText.class})
>>
>> Then the on-the-wire fault would look like:
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> <soap:Body>
>> <soap:Fault>
>> <faultcode>soap:Server</faultcode>
>> <faultstring>Only characters are allowed</faultstring>
>> <detail>
>> <ns2:uncheckedWrongText xmlns:ns2="http://spring.demo/">
>> <idx>0</idx>
>> <message>Only characters are allowed</message>
>> </ns2:uncheckedWrongText>
>> </detail>
>> </soap:Fault>
>> </soap:Body>
>> </soap:Envelope>
>>
>>
>> However, the client will still only get a SOAPFaultException. In this
>> case, though, the SOAPFaultException will have a getDetail() element
>> that contains the detail. Thus, it IS more information to the user.
>>
>>
>> ---
>> J. Daniel Kulp
>> Principal Engineer, IONA
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Handling-internal-errors-via-SOAP-faults-tp15892864p19967156.html
Sent from the cxf-user mailing list archive at Nabble.com.