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: axis-user@ws.apache.org 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: axis-user@ws.apache.org > 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: axis-user@ws.apache.org >>>>>>>> To: axis-user@ws.apache.org >>>>>>>> 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: axis-user@ws.apache.org >>>>>>>>>> To: axis-user@ws.apache.org >>>>>>>>>> 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/ >>>>>>> >>>>>>> >>>>>>> > >