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
> [EMAIL PROTECTED]
> 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.
