axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: [want exceptions in Java interface]
Date Tue, 19 Nov 2002 02:14:58 GMT
Steve, thanks for taking a shot at this.

I had earlier tried descending my custom exception class from 
RemoteException rather than just Exception. I ended up with the same meat 
byproducts in the WSDL. Subclassing AxisFault would have the same issue 
since it too is descended from RemoteException. Subclassing SOAPFault would 
not work because it's not a Throwable. In any event, in the interest of 
component separation, I don't want to be introducing Axis classes into my 
application logic.

I'm looking for a simplest, least-common-denominator way using the Axis 
tools to go from a Java interface with methods like:
public void doSuchAndSuch(String someParameter) throws SomeException
to an XML-RPC exchange where the response could contain a SOAP fault in 
place of the exception.

My vague understanding was that this was possible via Java2WSDL, WSDL2Java, 
filling in the *, and recompilation.

For what it's worth, running WSDL2Java on my hand-edited WSDL produces a 
* with methods that throw an exception class 
corresponding to my original exception class. For example:
public void undo() throws java.rmi.RemoteException, rootpack.axis.MyException {
The original exception class is something like rootpack.mypack.MyException. 
The package rootpack.axis is the package I specified using the -p parameter 
to WSDL2Java. So rootpack.axis.MyException is one of a number of 
rootpack.axis classes that are generated by WSDL2Java.  The classes in 
rootpack.axis parallel those in rootpack.mypack. Each original class is a 
beanable class exposed in my Java interface.

(Tangent. I had been under the impression that, with the exception of the 
*SoapBindingImpl and *SoapBindingSkeleton classes, these 
WSDL2Java-generated classes are needed only on the client side. However, 
that must not be the case since both the skeleton and binding 
implementation classes depend heavily on these classes.)

Perhaps I will try a more recent build, although I have been reluctant to 
get my hands dirty (no soap pun intended).

At 16:09 18.11.02 -0800, you wrote:

>I dont know the details, but
>1. Throw an AxisFault or a SoapFault and it should go over the wire as a
>soapfault+ADs- Declare you throw java.rmi.RemoteException and you can throw
>these, BTW. All proxy services built from a WSDL declaration throw
>RemoteException automatically
>2. To send other exceptions over the wire, try working with a recent (post
>1.0 build)
>----- Original Message -----
>From: +ACI-Mitch Gitman+ACI-
>Sent: Monday, November 18, 2002 3:16 PM
>Subject: Re: +AFs-want exceptions in Java interface+AF0-
>Well, I wound up working around the Axis tools+IBk- taking exception to
>Exception. I stripped the unwanted byproducts of java.lang.Exception from
>WSDL that Java2WSDL had generated. Then WSDL2Java worked just fine. I guess
>will just incorporate this editing of the .wsdl into my build.
>Still, there must be a more elegant solution. Something so basic as throwing
>an Exception in your Java interface should not require a workaround. Perhaps
>someone else on this list has had a similar experience.
>Mitch Gitman wrote:
>I have a minimal Java interface that I want to expose as a web service.
>Most of the methods in this interface throw a custom exception derived from
>Exception. Ultimately, through my RPC web service, I want these exceptions
>translate into SOAP faults. My understanding is that I don't have to be
>introducing AxisFault or SOAPFault objects into this interface.

View raw message