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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
