Ann, Steve -- I am working on a patch for Axis to implement just this functionality. There is one small clarification, however. The Axis engine is invoked on the client side via a call to javax.xml.rpc.Call.invoke(...). In Axis, this is actually implemented in org.apache.axis.client.Call.
However, these methods are defined as throwing java.rmi.RemoteException. Therefore, any exception returned by the engine -must- be a RemoteException. The Axis engine is not free to "map the SOAP fault to a local language exception and throw the appropriate exception" since it cannot itself throw checked exceptions unless they are RemoteExceptions. My solution is to enhance AxisFault, which extends RemoteException, so that AxisFault knows if it is just a "wrapper" for an ordinary exception thrown on the server side. If so, it is the stub that is then responsible for unwrapping the AxisFault and throwing the original exception. A .NET stub, for example, would also need to understand the deserialization of this AxisFault so that it could throw the corresponding exception on the .NET client side. Does this make sense? Gary > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 8:30 AM > To: [EMAIL PROTECTED] > Subject: Re: Soap Fault question > > > Steve, > > I don't think fault/exception behavior has been sufficiently > specified -- > hence the interop issues. > > The way it should work is thus: > > On the server side: > Application throws an exception in its native language. The exception > routine should map the error to a SOAP fault. The SOAP engine > should return > the SOAP fault. > > On the client side: > The SOAP engine receives the SOAP fault. It maps the SOAP > fault to a local > language exception and throws the appropriate exception. > > But to make that happen you need a way to properly configure the SOAP > engine to map the SOAP fault to the exception. > > When you have Java on both sides, the SOAP engines will automatically > handle throwing the appropriate exceptions for you, but they > don't really > map the exceptions to specific SOAP faults. Axis maps most > exceptions to > Server.userException (which doesn't make any sense -- if the error is > caused by the user, i.e., client -- then it should be mapped > to a Client > exception, not a Server exception). But anyway -- Axis > returns the Java > exception in the fault <details> element. If the client is > anything other > than Java, that exception won't be especially informative to > the client > application. > > Anne > At 10:33 AM 9/25/2003 -0500, you wrote: > > >Anyone else knowledgeable in Soap Faults have any comments on this? > > > >Steve > > > > > > > Steve, > > > > > > I am not knowledgeable enough to comment on whether your > > > expectations are > >too > > > high or not. However, it all boils down to WSDL to a particular > > > language binding and how that binding maps SOAP faults defined in > > > WSDL. I am not > >sure > > > whether there exists a standard language binding for each > language > > > (which > >may > > > or may not have a concept of exception e.g. a procedural language > > > like C) > >that > > > addresses SOAP fault to error handling strategy native to that > >programming > > > language. > > > Hope someone on the list can enlighten us ... > > > Thanks, > > > > > > Ajay > > > > > > > > > > > > > > > > > > "Steve Pannier" <[EMAIL PROTECTED]> > > > > > > 09/24/2003 09:58 PM > > > > > > Please respond to > > > [EMAIL PROTECTED] > > > > > > > > > > > > To > > > [EMAIL PROTECTED] > > > cc > > > > > > Subject > > > Re: Soap Fault question > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ajay, > > > > > > Thanks for the response. > > > > > > So maybe I'm not understanding the purpose for describing Soap > > > faults in a WSDL file. I was under the impression that a soap > > > implementation (regardless of language/programming environment) > > > would create the appropriate "exception class" (or object, or > > > whatever the case may be for that environment) for all soap faults > > > defined in the WSDL, so that a client developer could > > > "catch" a specific fault (as opposed to, for example, a > > > .NET client having to catch a general System.Exception, > > > then interrogate it further to find out exactly what went > > > wrong). > > > > > > All I'm trying to do is simply describe the custom exceptions my > > > service throws in my WSDL, and then test against various client > > > environments to insure my WSDL describes the faults > correctly. But > > > how do I test this against non-Java clients? Or even > Java clients > > > for that matter? > > > > > > Take the Axis samples/faults example. In VB .NET, after > retrieving > > > the WSDL, does the client have any knowledge at all about > > > NoSuchEmployeeFault? It didn't look like it when I tried > it. And > > > in BEA WebLogic (which generates Java client code), the > > > NoSuchEmployeeFault class it generated did not subclass from > > > Throwable, even though NoSuchEmployeeFault is described in > > > wsdl:fault elements in the WSDL. > > > > > > Am I expecting too much here? Is there a better way for > > > me to test that my custom faults are described correctly > > > in my WSDL? > > > > > > Is there anybody who can set this lost soul straight? > > > > > > Regards. > > > > > > Steve Pannier > > > > > > > > > > Steve, > > > > > > > > I have experimented a bit with SOAP faults on .NET side and > > > > server > >side > > > > exceptions on Axis side. As far as my understanding goes: > > > > - You can access the SOAP fault from .NET client. > However, that's > > > > "SOAP > > > fault" > > > > view - not the "Exception" view of the server side > problem. I have > > > > not > > > seen > > > > SOAP faults being converted to exceptions on the .NET > client side. > > > > In > >our > > > > > > > prototype, we are just accessing SOAP fault code, > string etc. We > > > > can > > > convert > > > > that to appropriate exception but that's application's > job not web > > > services > > > > infrastructure's job (in this case .NET) > > > > - I am not sure that a "custom" exception can be caught by > > > > non-Java > >(even > > > > > > > non-Axis clients implemented in Java) because there is > no standard > > > > (and > > > hence > > > > interoperable) way of communicating that this SOAP > fault maps to > > > > this > > > exception > > > > so that client side web services infrastructure can instantiate > > > > the > > > exception. > > > > In fact, you might consume a web service from a programming > > > > language > > > which does > > > > not have any concept of exception. In Axis > server-client scenario > > > > interoperability is not an issue. Axis client knows > where in the > > > > SOAP > > > fault to > > > > look for exception mapping information and as long as > client has > > > > the > > > exception > > > > class in the classpath it can instantiate the exception but > > > > achieving > >the > > > same > > > > thing in a language independent way is difficult and I > don't think > > > > web > > > services > > > > standards address this. Someone please correct me if my > > > > understanding > >is > > > not > > > > quite right .. > > > > > > > > Ajay > > > > > > > > > > > > > > > > > > > > "Steve Pannier" <[EMAIL PROTECTED]> > > > > > > > > 09/24/2003 02:54 AM > > > > > > > > Please respond to > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > To > > > > [EMAIL PROTECTED] > > > > cc > > > > > > > > Subject > > > > Soap Fault question > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Axis 1.1 > > > > > > > > I'm trying to get my web service to throw a > > > > custom exception subclassed from RemoteException. > > > > So to start off I looked at the code under samples/faults. I > > > > deployed the service, ran the supplied Axis client, everything > > > > looked good. (I had to 1st put a try/catch around the > call.invoke > > > > in the client to see if catching the > > > > NoSuchEmployeeFault exception really works). > > > > > > > > Now, my goal is to be able to support many different types of > > > > clients (.NET, JWSDP, BEA WebLogic, etc). So I tried > JWSDP: After > > > > getting the Employee.wsdl file from Axis, I generated > the client > > > > code. But it wouldn't compile, because the "cause" property > > > > in the generated exception class is defined as Object > > > > instead of Throwable. (Axis did inform me that "The > > > > class java.lang.Throwable is defined in a java or > > > > javax package and cannot be converted into an xml > > > > schema type. An xml schema anyType will be used to > > > > define this class in the wsdl file", so I knew > > > > something was amiss.) > > > > > > > > OK. So I moved on to VB .NET. I retrieved the WSDL > > > > and created my client code. I was able to catch > System.Exception, > > > > but not a NoSuchEmployeeFault exception. .NET did not > create an > > > > object to represent the NoSuchEmployeeFault exception. > > > > > > > > I tried BEA WebLogic also, but it didn't work there > either. The > > > > NoSuchEmployeeFault class it created does not subclass from > > > > Throwable, so it couldn't be used in a "catch" clause. > > > > > > > > So my questions: > > > > > > > > - Has anyone else got the samples/faults service > > > > code to work correctly against a non-Axis client environment? > > > > > > > > - Am I correct in assuming that my custom exception > > > > can be "caught" by any client, even if non-Java (provided my > > > > WSDL describes it correctly)? > > > > > > > > - In order to have Axis return a Soap Fault, is it a > requirement > > > > to add *all* the configuration information shown in the > > > > samples/faults deploy.wsdd file to my WSDD deployment > file? (i.e. > > > > Do I need to define all operation elements, even for > the methods > > > > that don't return a Soap fault?) > > > > > > > > Any examples would be greatly appreciated. > > > > > > > > Regards. > > > > > > > > Steve Pannier > > > > > > > > > > > > > > > > > > > > > > > >
