Well, I guess the question would be what do you mean by "correct". I get
XML very similar to what Jack got, namely:
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.userException</faultcode>
<faultstring>subprod.dis.fault.MVException: Hello world my
...</faultstring>
<detail>
<subprod.dis.fault.MVException xsi:type="ns1:MVFault"
xmlns:ns1="urn:Faults">
<codes soapenc:arrayType="xsd:anyType[3]"
xsi:type="soapenc:Array"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";>
<codes xsi:type="soapenc:string">BAD_DAY</codes>
<codes xsi:type="soapenc:string">RAIN</codes>
<codes xsi:type="soapenc:string">WS_SUCK</codes>
</codes>
</subprod.dis.fault.MVException>
<ns2:hostname xmlns:ns2="http://xml.apache.org/axis/";>
myhost</ns2:hostname>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
It obviously is not formated this way, I made it more readable (tried at
least). Basically what I did was I extended Exception with my own class
and added a list of error codes (just a list of Strings called "codes",
list is not typed)
As you can see, I get this fault and I can deserialize it (and I can
probably even get into "details"). It is possible that if I generate a
client with WSDL2Java (for now I just use Call class) I will even get
this exception (not sure, would need to test). However as I mentioned
before the service is supposed to be cross-platform so I would very much
like to control faultcode and faultstring so that C++ or Python would be
able to process it. I can probably get them to process custom XML but
you must agree this kinda violates the purpose of using SOAP in the
first place.
I was able to set both values I need through making my exception extend
AxisFault, which is an option, but I wanted to see if there are other
options too (namely custom serialization of standard exceptions).
Another question - I think SOAP allows to have multiple Faults in one
response. Is this correct and if it is, is there a way to have multiple
faults with Axis?
Thank you,
-Michael
___________________
Tell a man there are 300 billion stars in the universe and he'll believe
Tell him a bench has wet paint on it and he'll have to touch to be sure
-- /usr/bin/fortune
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Thom Hehl
Sent: Thursday, April 06, 2006 5:10 AM
To: [email protected]
Subject: Re: [SPAM] - Re: [SPAM] - Re: Problems getting user exceptions
to work - Found word(s) check out in the Text body - Found word(s) check
out in the subject
Right. We use the WSDL to build java from, not the other way round. The
problem is a bug in axis. We're going to write it up when we get the
chance. In the meantime, you will need to decide whether or not to
modify the WSDL.
I will bet that if you look at the XML coming from the server, it is
correct. The problem lies in the de-serialization of the fault. This is
a work-around for that problem.
Veprinsky, Michael wrote:
> Hello!
> I decided to piggy-back on this thread... I am having similar
> problems.
>
> Thom,
> What did you mean? I suppose recommend changing WSDL definition but a)
> my WSDL is auto-published so I can't really change it and b) even if I
> do, it does not change the XML that server generates and that is
> totally language-specific which kinda violates the purpose. Or did you
> mean something else?
>
> I am using Axis 1.3. I have following questions:
> 1) Is there a way to set server to use SOAP 1.2 (RTFMs are welcome,
> just tell where)?
> 2) Is there a way to specify custom values for faultcode/faultstring?
> Best I could get was my exception being serialized into XML under
> details but then I have to process it as XML :-\
> 3) Overall, I need to publish a web service that is going to be used
> from different platforms. Is my best bet to just give up faults
> altogether and use some custom base result structure with generic
> error passing engine? Any recommendations (again, RTFMs are welcome)
>
> I do not expect much success since the envelope XSD itself is pretty
> limiting (http://schemas.xmlsoap.org/soap/envelope, toward the end),
> it's just those two fields and freeform XML "details". SOAP 1.2 looks
> a little better but without documentation it did not help much either.
>
> Any recommendations/insights are welcome.
> Thank you,
> -Michael
>
> ___________________
> Tell a man there are 300 billion stars in the universe and he'll
> believe Tell him a bench has wet paint on it and he'll have to touch
to be sure
> -- /usr/bin/fortune
>
>
> -----Original Message-----
> From: Thom Hehl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 30, 2006 1:47 PM
> To: [email protected]
> Subject: Re: [SPAM] - Re: [SPAM] - Re: Problems getting user
exceptions
> to work - Found word(s) check out in the Text body - Found word(s)
check
> out in the subject
>
>
> Have a look at this:
>
> Give him This:
> _____original type def from imported xsd___________________
> <complexType name="InvalidDateException">
> <sequence/>
> </complexType>
>
> _____also needed in wsdl file___________
> <wsdl:message name="InvalidDateExceptionFault">
> <wsdl:part name="InvalidDateExceptionType"
> type="ns:InvalidDateException"/>
> </wsdl:message>
>
> *(in the portType operation definition for a method throwing a fault)*
> <wsdl:fault name="InvalidDateExceptionFault"
> message="ns:InvalidDateExceptionFault"/>
>
> *(in the binding operation definintion for a method throwing a fault)*
> <wsdl:fault name="InvalidDateExceptionFault">
> <soap:fault use="literal" name="InvalidDateExceptionFault"/>
> </wsdl:fault>
>
>
>
> Jack Lund wrote:
>
>
>> See, I'm not really sure. The JAX/RPC spec is kinda hazy on how
>> exceptions are handled, and how the soap fault maps to an exception.
>> Here's what I'm seeing come back from the server:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <soapenv:Envelope
>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>> <soapenv:Body>
>> <soapenv:Fault>
>> <faultcode>soapenv:Server.userException</faultcode>
>> <faultstring>com.foobar.ecommerce.beans.InvalidDateException:
A
>>
>
>
>> valid date must be specified in the form of MM/DD/YYYY.</faultstring>
>> <detail>
>> <com.foobar.ecommerce.beans.InvalidDateException
>> xsi:type="ns1:InvalidDateException" xmlns:ns1="urn:ClaimsData"/>
>> <ns2:hostname
>>
>>
> xmlns:ns2="http://xml.apache.org/axis/";>staportal01.stratarc.net</ns2:
> ho
> stname>
>
>> </detail>
>> </soapenv:Fault>
>> </soapenv:Body>
>> </soapenv:Envelope>
>>
>> And here's what the corresponding part of the WSDL looks like:
>>
>> <wsdl:types>
>> <schema targetNamespace="urn:ClaimsData"
>> xmlns="http://www.w3.org/2001/XMLSchema";>
>> <import namespace="http://hib.ecommerce.foobar.com"/>
>> <import
>>
namespace="http://portal01.foobar.com:8080/axis/services/ClaimsData"/>
>> <import namespace="http://dao.ecommerce.foobar.com"/>
>> <import namespace="http://beans.ecommerce.foobar.com"/>
>> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
>> <complexType name="Claim">
>> <sequence>
>> <element name="amount" type="xsd:double"/>
>> <element name="claimDate" nillable="true" type="xsd:dateTime"/>
>> <element name="claimDesc" nillable="true" type="xsd:string"/>
>> <element name="claimID" type="xsd:long"/>
>> <element name="claimNumber" nillable="true" type="xsd:string"/>
>> <element name="claimStatus" nillable="true" type="xsd:string"/>
>> <element name="claimStatusName" nillable="true"
>>
> type="xsd:string"/>
>
>> <element name="formattedDate" nillable="true" type="xsd:string"/>
>> <element name="policy" nillable="true" type="xsd:anyType"/>
>> <element name="policyHolder" nillable="true" type="xsd:string"/>
>> <element name="provider" nillable="true" type="xsd:anyType"/>
>> </sequence>
>> </complexType>
>> <complexType name="InvalidDateException">
>> <sequence/>
>> </complexType>
>> </schema>
>>
>> What makes me think the serialization isn't working is that the
>> definition of the InvalidDateException is pretty much empty. However,
>> it also looks like there's enough information in the passed soap
>> message to be able to deserialize the exception properly, so I don't
>> really know what's going on here.
>>
>> Do you (or anybody) have an example of what a "good" soap fault
>> mapped from a java exception looks like?
>>
>> Thanks.
>>
>> -Jack
>>
>>
>> Thom Hehl wrote:
>>
>>
>>> Hmmm. Check your SOAP messae. Our problem is that we're sending the
>>> correct data from the server and the error happens during
>>> deserialization. If that's not it, it's a different problem.
>>>
>>> Jack Lund wrote:
>>>
>>>
>>>> Thanks! I'd love to hear the workaround - I've tried everything I
>>>> can. It looks like the problem is that the server side doesn't
>>>> really know how to serialize the exception, even though it should.
>>>>
>>>> -Jack
>>>>
>>>> Thom Hehl wrote:
>>>>
>>>>
>>>>> We had EXACTLY the same problem! We just found it and found a
>>>>> work-around, but believe this to be a bug in AXIS that should be
>>>>> fixed. The guy on our team that found it was going to write
>>>>> something up for the list. I'll ask him to step this up a bit as
>>>>> it
>>>>>
>
>
>>>>> would be of benefit to you.
>>>>>
>>>>> Jack Lund wrote:
>>>>>
>>>>>
>>>>>> Yeah, I can see that that would be easier. Unfortunately, I have
>>>>>> no control over the exceptions being thrown - I just need the
>>>>>> client-side to be able to catch them *as* the exceptions that are
>>>>>> originally thrown. I also am doing dynamic proxying rather than
>>>>>> stubs/skeletons, so it makes it that more complicated.
>>>>>>
>>>>>> >From the debugging I've been able to do, it looks like the fault
>>>>>> coming across contains the fully-qualified package name of the
>>>>>> exception class, but for some reason on the client side it's not
>>>>>> creating the exception. Since this is an area where there's
>>>>>> practically no documentation, I'm finding myself pretty much
>>>>>> randomly trying different things and seeing if they work.
>>>>>>
>>>>>> The user's guide is really vague about this subject:
>>>>>>
>>>>>> "If a method is marked as throwing an Exception that is not an
>>>>>> instance or a subclass of java.rmi.RemoteException, then things
>>>>>> are subtly different. The exception is no longer a SOAP Fault,
>>>>>> but
>>>>>>
>
>
>>>>>> described as a wsdl:fault in the WSDL of the method. According to
>>>>>> the JAX-RPC specification, your subclass of Exception must have
>>>>>> accessor methods to access all the fields in the object to be
>>>>>> marshalled /and/ a constructor that takes as parameters all the
>>>>>> same fields (i.e, arguments of the same name and type). This is a
>>>>>> kind of immutable variant of a normal JavaBean
>>>>>> <http://java.sun.com/products/javabeans>. The fields in the
object
>>>>>>
>
>
>>>>>> must be of the datatypes that can be reliably mapped into WSDL.
>>>>>>
>>>>>> If your exception meets this specification, then the WSDL
>>>>>> describing the method will describe the exception too, enabling
>>>>>> callers to create stub implementations of the exception,
>>>>>> regardless of platform."
>>>>>>
>>>>>> I was kind of hoping someone else out there would have had some
>>>>>> experience with getting this to work.
>>>>>>
>>>>>> -Jack
>>>>>>
>>>>>> Jarmo Doc wrote:
>>>>>>
>>>>>>
>>>>>>> I have an Axis client stub which was generated from WSDL. *All*
>>>>>>> of the client-side user-defined exceptions extend
>>>>>>> org.apache.axis.AxisFault.
>>>>>>>
>>>>>>> The equivalent exceptions at the server also extend
>>>>>>> org.apache.axis.AxisFault, rather than Exception.
>>>>>>>
>>>>>>> This is a decidedly dodgy area, imo, especially when it comes to
>>>>>>> interop with non-Axis clients.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> From: Jack Lund <[EMAIL PROTECTED]>
>>>>>>>> Reply-To: [email protected]
>>>>>>>> To: [email protected]
>>>>>>>> Subject: RE: Problems getting user exceptions to work
>>>>>>>> Date: Wed, 29 Mar 2006 14:51:47 -0600
>>>>>>>>
>>>>>>>> Nope, didn't work. Wouldn't think it would - AxisFault isn't a
>>>>>>>> subclass of InvalidDateException.
>>>>>>>>
>>>>>>>> -Jack
>>>>>>>>
>>>>>>>> Jarmo Doc wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Try doing this:
>>>>>>>>>
>>>>>>>>> catch (AxisFault ex)
>>>>>>>>> {
>>>>>>>>> if (ex instanceof InvalidDateException)
>>>>>>>>> {
>>>>>>>>> InvalidDateException myex = (InvalidDateException)ex; // deal
>>>>>>>>> with myex here }
>>>>>>>>> // deal with others here
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> From: Jack Lund <[EMAIL PROTECTED]>
>>>>>>>>>> Reply-To: [email protected]
>>>>>>>>>> To: [email protected]
>>>>>>>>>> Subject: Problems getting user exceptions to work
>>>>>>>>>> Date: Wed, 29 Mar 2006 12:21:33 -0600
>>>>>>>>>>
>>>>>>>>>> Hi. I'm using axis 1.2.1, and I'm trying to get the
>>>>>>>>>> exceptions sent by my service thrown to the client. For
>>>>>>>>>> instance, my service can throw an "InvalidDateException"
>>>>>>>>>> exception, which is a subclass of java.lang.Exception, and I
>>>>>>>>>> want the client code to get that exception. What little is
>>>>>>>>>> said on the axis website about this implies that it should
>>>>>>>>>> "just work", but it doesn't seem to - what I get on the other
>>>>>>>>>> side is an AxisFault
>>>>>>>>>>
>
>
>>>>>>>>>> with the message string from my exception embedded inside.
>>>>>>>>>>
>>>>>>>>>> Is there something special I have to do, on either side, to
>>>>>>>>>> get this to work?
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> -Jack
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ______________________________________________________________
>>>>>>>>> _
>>>>>>>>> __
>>>>>>>>> Don't just search. Find. Check out the new MSN Search!
>>>>>>>>> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> ________________________________________________________________
>>>>>>> _
>>>>>>> Express yourself instantly with MSN Messenger! Download today -
>>>>>>> it's FREE!
>>>>>>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>>>>>>
>>>>>>>
>>>>>>>
>
>
