You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jack Lund <ja...@stagrp.com> on 2006/03/29 20:21:33 UTC
Problems getting user exceptions to work
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
Re: Problems getting user exceptions to work
Posted by Dies Koper <di...@jp.fujitsu.com>.
Hello Jack,
I'm afraid I've always used stubs and am not sure how things work in the
case of DII. I naively assumed one would still use generated classes
(except for the stubs).
I reread the section in the JAX-RPC spec and javadoc about it, and this
is what I'd expect to happen.
DII is for when you dynamically call methods, i.e. you do not know the
operation names, parameters, etc. at compile time. This also means you
would not know what faults might get thrown.
The javadoc explains that the Call.invoke methods throw a
SOAPFaultException in case of SOAP faults, and a
java.rmi.RemoteException in case of "any error in the remote method
invocation".
I.e. all checked exceptions that you throw from your endpoint's methods
get mapped to these exceptions. The SOAPFaultException class has methods
to get information about the actual fault that occurred.
You get a RemoteException (AxisFault instance)?
I would expect "error in the invocation" to mean errors in calling the
method, communication related. Maybe the Axis developer sees user
exceptions as "errors in the invocation" and throws a RemoteException
instead of a SOAPFaultException?
You could try raising this issue on the axis-developers ML.
Unfortunately, such questions often do not get replied :(
At least I think I understand (and maybe share) part of your frustration
now.
Good luck,
Dies
Jack Lund wrote:
> Thanks for taking the time to answer me so thoroughly. I really, really
> appreciate it.
>
> Dies Koper wrote:
>
>> I am not sure about meaning of "The exception is no longer a SOAP
>> Fault" in your quote of the User's Guide, as a fault described in the
>> WSDL is still a SOAP fault when it is included in the SOAP body.
>>
>> I do not think I contradicted anything in the quote. It refers to the
>> JAX-RPC 1.1 spec. I also got my information from there, so you should
>> just be seeing different ways of saying the same.
>
> Well, from the quote, it looks like they're saying that all you need to
> do to pass exceptions is a) inherit from Exception, and b) be a javabean
> whose fields are wsdl-able datatypes. It never mentions that you have to
> inherit from AxisFault.
>
>> As you have probably noticed, in this mailing list the recommended
>> approach with Axis seems to be to start with the WSDL (maybe the first
>> draft generated by Java2WSDL). You tweak the WSDL into the service you
>> want, and develop the client and server implementations from there.
>> Axis also allows you to take a different approach, but I would not be
>> surprised if there are more bugs on that path.
>>
>> I still do not understand whether you delete the generated exceptions
>> and use your own.
>
> I don't generate exceptions at all. I never do Java2WSDL or WSDL2Java.
> The service class, data and exceptions are all standard Java classes.
>
>> Do you want to discuss the validity of Axis's implementation or get
>> your problem solved? I'm fine with either, just want to know how to
>> answer.
>
> I apologize for my frustration level. I have no problems with Axis's
> implementation - what I've been able to see of it is really, really
> great. My only problem is the lack of documentation, especially in an
> area as fundamental as exception handling.
>
>> Please look at the generated interface, javabeans and exception
>> classes as not being part of your client, but part of Axis's
>> WSDL->Java mapping.
>> Your client class does not need to have any dependencies on axis
>> classes. Just catch the InvalidDateException and don't care whether it
>> extends AxisFault internally. It is just a generated class that would
>> be regenerated anyway if you would use a different SOAP engine.
>
> I think that's the disconnect we're having here. I'm not generating
> anything, nor am I interested in generating anything. From what I've
> been able to see, Axis provides me with the ability to drop a standard
> Java class into its container, without having to do any code generation,
> and it will automatically create the service. I've already taken
> advantage of that, and it works great. Unfortunately, it doesn't seem to
> handle exceptions the same way, which is why I was so confused. What you
> seem to be saying is that I have to generate the code from the WSDL (or,
> alternatively, generate the WSDL from the java class and then generate
> the client and exceptions from the WSDL) in order to have exception
> handling. Unfortunately, that's not something I can do, because of the
> architectural and technical constraints of the project.
>
> I can write something which intercepts the exceptions before they get to
> Axis on the server side, and wrap them in an AxisFault, but it will be
> an enormous pain. I was hoping that Axis would do that. They're
> obviously already catching exceptions on the server side, and I was
> hoping that they would just serialize it just as they would any other
> class going across the wire, which is what I thought that section in the
> user's guide was saying. Unfortunately, it sounds like this isn't the case.
>
>>> 3) There is no number 3. ;-)
>>
>>
>> Maybe later? :)
>
> You never know. :)
>
>>> It doesn't make much sense to me that axis would have this wonderful
>>> mechanism whereby we can install a fairly arbitrary Java class and
>>> turn it magically into a web service...unless you throw exceptions,
>>> in which case all bets are off. Of course, I've been wrong before.
>>
>>
>> I am wondering whether you just ran into a bug or expect something
>> from Axis that it was not designed to do.
>
> Don't know. I guess we may never know - unless I stumble on the solution
> randomly. Weirder stuff has happened before.
>
> Thanks again for taking the time to answer my questions.
>
> Jack
Re: Problems getting user exceptions to work
Posted by Jack Lund <ja...@stagrp.com>.
Thanks for taking the time to answer me so thoroughly. I really, really
appreciate it.
Dies Koper wrote:
> I am not sure about meaning of "The exception is no longer a SOAP
> Fault" in your quote of the User's Guide, as a fault described in the
> WSDL is still a SOAP fault when it is included in the SOAP body.
>
> I do not think I contradicted anything in the quote. It refers to the
> JAX-RPC 1.1 spec. I also got my information from there, so you should
> just be seeing different ways of saying the same.
Well, from the quote, it looks like they're saying that all you need to
do to pass exceptions is a) inherit from Exception, and b) be a javabean
whose fields are wsdl-able datatypes. It never mentions that you have to
inherit from AxisFault.
> As you have probably noticed, in this mailing list the recommended
> approach with Axis seems to be to start with the WSDL (maybe the first
> draft generated by Java2WSDL). You tweak the WSDL into the service you
> want, and develop the client and server implementations from there.
> Axis also allows you to take a different approach, but I would not be
> surprised if there are more bugs on that path.
>
> I still do not understand whether you delete the generated exceptions
> and use your own.
I don't generate exceptions at all. I never do Java2WSDL or WSDL2Java.
The service class, data and exceptions are all standard Java classes.
> Do you want to discuss the validity of Axis's implementation or get
> your problem solved? I'm fine with either, just want to know how to
> answer.
I apologize for my frustration level. I have no problems with Axis's
implementation - what I've been able to see of it is really, really
great. My only problem is the lack of documentation, especially in an
area as fundamental as exception handling.
> Please look at the generated interface, javabeans and exception
> classes as not being part of your client, but part of Axis's
> WSDL->Java mapping.
> Your client class does not need to have any dependencies on axis
> classes. Just catch the InvalidDateException and don't care whether it
> extends AxisFault internally. It is just a generated class that would
> be regenerated anyway if you would use a different SOAP engine.
I think that's the disconnect we're having here. I'm not generating
anything, nor am I interested in generating anything. From what I've
been able to see, Axis provides me with the ability to drop a standard
Java class into its container, without having to do any code generation,
and it will automatically create the service. I've already taken
advantage of that, and it works great. Unfortunately, it doesn't seem to
handle exceptions the same way, which is why I was so confused. What you
seem to be saying is that I have to generate the code from the WSDL (or,
alternatively, generate the WSDL from the java class and then generate
the client and exceptions from the WSDL) in order to have exception
handling. Unfortunately, that's not something I can do, because of the
architectural and technical constraints of the project.
I can write something which intercepts the exceptions before they get to
Axis on the server side, and wrap them in an AxisFault, but it will be
an enormous pain. I was hoping that Axis would do that. They're
obviously already catching exceptions on the server side, and I was
hoping that they would just serialize it just as they would any other
class going across the wire, which is what I thought that section in the
user's guide was saying. Unfortunately, it sounds like this isn't the case.
>> 3) There is no number 3. ;-)
>
>
> Maybe later? :)
You never know. :)
>> It doesn't make much sense to me that axis would have this wonderful
>> mechanism whereby we can install a fairly arbitrary Java class and
>> turn it magically into a web service...unless you throw exceptions,
>> in which case all bets are off. Of course, I've been wrong before.
>
>
> I am wondering whether you just ran into a bug or expect something
> from Axis that it was not designed to do.
Don't know. I guess we may never know - unless I stumble on the solution
randomly. Weirder stuff has happened before.
Thanks again for taking the time to answer my questions.
Jack
Re: Problems getting user exceptions to work
Posted by Dies Koper <di...@jp.fujitsu.com>.
I am not sure about meaning of "The exception is no longer a SOAP Fault"
in your quote of the User's Guide, as a fault described in the WSDL is
still a SOAP fault when it is included in the SOAP body.
I do not think I contradicted anything in the quote. It refers to the
JAX-RPC 1.1 spec. I also got my information from there, so you should
just be seeing different ways of saying the same.
As you have probably noticed, in this mailing list the recommended
approach with Axis seems to be to start with the WSDL (maybe the first
draft generated by Java2WSDL). You tweak the WSDL into the service you
want, and develop the client and server implementations from there.
Axis also allows you to take a different approach, but I would not be
surprised if there are more bugs on that path.
I still do not understand whether you delete the generated exceptions
and use your own. Do you want to discuss the validity of Axis's
implementation or get your problem solved? I'm fine with either, just
want to know how to answer.
> What I'm trying to do is this: We've got a service, which is basically a
> POJO (i.e. no axis-isms or web service-isms) that we're deploying using
> wsdd (a minimal wsdd) without generating WSDL or any of that. On the
> client side, I'm creating a dynamic proxy which uses the sample code
> example to parse the axis-generated WSDL (the one you get from
> http://foo.com/axis/service/myService?wsdl) and figure out how to call
> the method and get everything back. Everything works just fine except
> for exceptions.
The WSDL looks fine to me. I do not think it needs editing.
> I'd rather not extend AxisFault for a couple of reasons:
>
> 1) My service right now has no knowledge that it's running within Axis,
> or even that it's a web service. I'd like to keep it that way
Please look at the generated interface, javabeans and exception classes
as not being part of your client, but part of Axis's WSDL->Java mapping.
Your client class does not need to have any dependencies on axis
classes. Just catch the InvalidDateException and don't care whether it
extends AxisFault internally. It is just a generated class that would be
regenerated anyway if you would use a different SOAP engine.
> 2) My client may be accessing web services which aren't in my control. I
> can't assume that they're going to throw exceptions which inherit from
> AxisFault.
If you choose to use Axis DII or stubs, then they will. But your client
does not need to know.
> 3) There is no number 3. ;-)
Maybe later? :)
> It doesn't make much sense to me that axis would have this wonderful
> mechanism whereby we can install a fairly arbitrary Java class and turn
> it magically into a web service...unless you throw exceptions, in which
> case all bets are off. Of course, I've been wrong before.
I am wondering whether you just ran into a bug or expect something from
Axis that it was not designed to do.
Regards,
Dies
Re: Problems getting user exceptions to work
Posted by Jack Lund <ja...@stagrp.com>.
Um, but that contradicts the section of the User's guide I quoted below.
Is the User's guide wrong? That would be unfortunate, because I've
wasted a couple of days on the assumption that it's correct.
What I'm trying to do is this: We've got a service, which is basically a
POJO (i.e. no axis-isms or web service-isms) that we're deploying using
wsdd (a minimal wsdd) without generating WSDL or any of that. On the
client side, I'm creating a dynamic proxy which uses the sample code
example to parse the axis-generated WSDL (the one you get from
http://foo.com/axis/service/myService?wsdl) and figure out how to call
the method and get everything back. Everything works just fine except
for exceptions.
I'd rather not extend AxisFault for a couple of reasons:
1) My service right now has no knowledge that it's running within Axis,
or even that it's a web service. I'd like to keep it that way
2) My client may be accessing web services which aren't in my control. I
can't assume that they're going to throw exceptions which inherit from
AxisFault.
3) There is no number 3. ;-)
It doesn't make much sense to me that axis would have this wonderful
mechanism whereby we can install a fairly arbitrary Java class and turn
it magically into a web service...unless you throw exceptions, in which
case all bets are off. Of course, I've been wrong before.
Here's the wsdd file:
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="ClaimsData" provider="java:RPC">
<parameter name="className"
value="com.foo.ecommerce.dataservice.ClaimDataService"/>
<parameter name="allowedMethods" value="*"/>
<beanMapping qname="myNS:Claim" xmlns:myNS="urn:ClaimsData"
languageSpecificType="java:com.foo.ecommerce.beans.Claim"/>
</service>
</deployment>
Here's the generated WSDL:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" xmlns:intf="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns1="urn:ClaimsData" xmlns:tns2="http://beans.ecommerce.foo.com" xmlns:tns3="http://dao.ecommerce.foo.com" xmlns:tns4="http://hib.ecommerce.foo.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.3
Built on Oct 05, 2005 (05:23:37 EDT)-->
<wsdl:types>
<schema targetNamespace="urn:ClaimsData" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://hib.ecommerce.foo.com"/>
<import namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData"/>
<import namespace="http://dao.ecommerce.foo.com"/>
<import namespace="http://beans.ecommerce.foo.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>
</schema>
<schema targetNamespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://hib.ecommerce.foo.com"/>
<import namespace="http://dao.ecommerce.foo.com"/>
<import namespace="urn:ClaimsData"/>
<import namespace="http://beans.ecommerce.foo.com"/>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="ArrayOf_tns1_Claim">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="tns1:Claim[]"/>
</restriction>
</complexContent>
</complexType>
</schema>
<schema targetNamespace="http://beans.ecommerce.foo.com" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://hib.ecommerce.foo.com"/>
<import namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData"/>
<import namespace="http://dao.ecommerce.foo.com"/>
<import namespace="urn:ClaimsData"/>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="InvalidDateException">
<sequence/>
</complexType>
</schema>
<schema targetNamespace="http://dao.ecommerce.foo.com" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://hib.ecommerce.foo.com"/>
<import namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData"/>
<import namespace="urn:ClaimsData"/>
<import namespace="http://beans.ecommerce.foo.com"/>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="ClaimDataAccessException">
<sequence/>
</complexType>
</schema>
<schema targetNamespace="http://hib.ecommerce.foo.com" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData"/>
<import namespace="http://dao.ecommerce.foo.com"/>
<import namespace="urn:ClaimsData"/>
<import namespace="http://beans.ecommerce.foo.com"/>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="HibernateException">
<sequence/>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="getClaimsByDateRequest">
<wsdl:part name="beginDate" type="soapenc:string"/>
<wsdl:part name="endDate" type="soapenc:string"/>
</wsdl:message>
<wsdl:message name="getClaimsByProviderNameResponse">
<wsdl:part name="getClaimsByProviderNameReturn" type="impl:ArrayOf_tns1_Claim"/>
</wsdl:message>
<wsdl:message name="ClaimDataAccessException">
<wsdl:part name="fault" type="tns3:ClaimDataAccessException"/>
</wsdl:message>
<wsdl:message name="getClaimsByProviderRequest">
<wsdl:part name="providerID" type="soapenc:string"/>
</wsdl:message>
<wsdl:message name="getClaimsByProviderNameRequest">
<wsdl:part name="providerID" type="soapenc:string"/>
<wsdl:part name="name" type="soapenc:string"/>
</wsdl:message>
<wsdl:message name="addClaimRequest">
<wsdl:part name="claim" type="tns1:Claim"/>
</wsdl:message>
<wsdl:message name="addClaimResponse">
</wsdl:message>
<wsdl:message name="getClaimsByProviderDateRequest">
<wsdl:part name="providerID" type="soapenc:string"/>
<wsdl:part name="beginDate" type="soapenc:string"/>
<wsdl:part name="endDate" type="soapenc:string"/>
</wsdl:message>
<wsdl:message name="getClaimsByProviderResponse">
<wsdl:part name="getClaimsByProviderReturn" type="impl:ArrayOf_tns1_Claim"/>
</wsdl:message>
<wsdl:message name="getClaimsByProviderDateResponse">
<wsdl:part name="getClaimsByProviderDateReturn" type="impl:ArrayOf_tns1_Claim"/>
</wsdl:message>
<wsdl:message name="getClaimsByDateResponse">
<wsdl:part name="getClaimsByDateReturn" type="impl:ArrayOf_tns1_Claim"/>
</wsdl:message>
<wsdl:message name="InvalidDateException">
<wsdl:part name="fault" type="tns2:InvalidDateException"/>
</wsdl:message>
<wsdl:message name="HibernateException">
<wsdl:part name="fault" type="tns4:HibernateException"/>
</wsdl:message>
<wsdl:portType name="ClaimDataService">
<wsdl:operation name="getClaimsByDate" parameterOrder="beginDate endDate">
<wsdl:input message="impl:getClaimsByDateRequest" name="getClaimsByDateRequest"/>
<wsdl:output message="impl:getClaimsByDateResponse" name="getClaimsByDateResponse"/>
<wsdl:fault message="impl:ClaimDataAccessException" name="ClaimDataAccessException"/>
<wsdl:fault message="impl:InvalidDateException" name="InvalidDateException"/>
</wsdl:operation>
<wsdl:operation name="getClaimsByProvider" parameterOrder="providerID">
<wsdl:input message="impl:getClaimsByProviderRequest" name="getClaimsByProviderRequest"/>
<wsdl:output message="impl:getClaimsByProviderResponse" name="getClaimsByProviderResponse"/>
<wsdl:fault message="impl:ClaimDataAccessException" name="ClaimDataAccessException"/>
</wsdl:operation>
<wsdl:operation name="getClaimsByProviderName" parameterOrder="providerID name">
<wsdl:input message="impl:getClaimsByProviderNameRequest" name="getClaimsByProviderNameRequest"/>
<wsdl:output message="impl:getClaimsByProviderNameResponse" name="getClaimsByProviderNameResponse"/>
<wsdl:fault message="impl:ClaimDataAccessException" name="ClaimDataAccessException"/>
</wsdl:operation>
<wsdl:operation name="getClaimsByProviderDate" parameterOrder="providerID beginDate endDate">
<wsdl:input message="impl:getClaimsByProviderDateRequest" name="getClaimsByProviderDateRequest"/>
<wsdl:output message="impl:getClaimsByProviderDateResponse" name="getClaimsByProviderDateResponse"/>
<wsdl:fault message="impl:ClaimDataAccessException" name="ClaimDataAccessException"/>
<wsdl:fault message="impl:InvalidDateException" name="InvalidDateException"/>
</wsdl:operation>
<wsdl:operation name="addClaim" parameterOrder="claim">
<wsdl:input message="impl:addClaimRequest" name="addClaimRequest"/>
<wsdl:output message="impl:addClaimResponse" name="addClaimResponse"/>
<wsdl:fault message="impl:ClaimDataAccessException" name="ClaimDataAccessException"/>
<wsdl:fault message="impl:HibernateException" name="HibernateException"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="ClaimsDataSoapBinding" type="impl:ClaimDataService">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getClaimsByDate">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getClaimsByDateRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://dataservice.ecommerce.foo.com" use="encoded"/>
</wsdl:input>
<wsdl:output name="getClaimsByDateResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:output>
<wsdl:fault name="ClaimDataAccessException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ClaimDataAccessException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
<wsdl:fault name="InvalidDateException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="InvalidDateException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="getClaimsByProvider">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getClaimsByProviderRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://dataservice.ecommerce.foo.com" use="encoded"/>
</wsdl:input>
<wsdl:output name="getClaimsByProviderResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:output>
<wsdl:fault name="ClaimDataAccessException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ClaimDataAccessException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="getClaimsByProviderName">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getClaimsByProviderNameRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://dataservice.ecommerce.foo.com" use="encoded"/>
</wsdl:input>
<wsdl:output name="getClaimsByProviderNameResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:output>
<wsdl:fault name="ClaimDataAccessException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ClaimDataAccessException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="getClaimsByProviderDate">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getClaimsByProviderDateRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://dataservice.ecommerce.foo.com" use="encoded"/>
</wsdl:input>
<wsdl:output name="getClaimsByProviderDateResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:output>
<wsdl:fault name="ClaimDataAccessException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ClaimDataAccessException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
<wsdl:fault name="InvalidDateException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="InvalidDateException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
<wsdl:operation name="addClaim">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="addClaimRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://dataservice.ecommerce.foo.com" use="encoded"/>
</wsdl:input>
<wsdl:output name="addClaimResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:output>
<wsdl:fault name="ClaimDataAccessException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="ClaimDataAccessException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
<wsdl:fault name="HibernateException">
<wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="HibernateException" namespace="http://staportal01.stratarc.net:8080/axis/services/ClaimsData" use="encoded"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ClaimDataServiceService">
<wsdl:port binding="impl:ClaimsDataSoapBinding" name="ClaimsData">
<wsdlsoap:address location="http://staportal01.stratarc.net:8080/axis/services/ClaimsData"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Thanks.
-Jack
Dies Koper wrote:
> Hello Jack,
>
> As Jarmo pointed out, all client-side (generated) exceptions extend
> AxisFault. Are you not using the generated exceptions?
> The WSDL defines the interface, including the faults. Either you let
> Axis do the mapping to Java using its own generated classes, or you do
> not. I don't think Axis could do its job without them.
>
> There is no need to catch an AxisFault first and then doing an
> instanceof. Jarmo must have written that code before he had his coffee ;)
> Your client does not (and should not) need to know that AxisFault is
> being used internally.
>
> Could you show us the WSDL that defines your fault (complexType +
> <message>, etc.), the SOAP response containing the fault, and the code
> you use to catch the exception?
>
> Regards,
> Dies
>
> 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 <ja...@stagrp.com>
>>>> 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 <ja...@stagrp.com>
>>>>>> 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
>>>>>
>
>
>
Re: Problems getting user exceptions to work
Posted by Dies Koper <di...@jp.fujitsu.com>.
Hello Jack,
As Jarmo pointed out, all client-side (generated) exceptions extend
AxisFault. Are you not using the generated exceptions?
The WSDL defines the interface, including the faults. Either you let
Axis do the mapping to Java using its own generated classes, or you do
not. I don't think Axis could do its job without them.
There is no need to catch an AxisFault first and then doing an
instanceof. Jarmo must have written that code before he had his coffee ;)
Your client does not (and should not) need to know that AxisFault is
being used internally.
Could you show us the WSDL that defines your fault (complexType +
<message>, etc.), the SOAP response containing the fault, and the code
you use to catch the exception?
Regards,
Dies
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 <ja...@stagrp.com>
>>> 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 <ja...@stagrp.com>
>>>>> 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
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
Posted by Thom Hehl <he...@asset.com>.
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:hostname>
>
> </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 <ja...@stagrp.com>
>>>>>>> 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 <ja...@stagrp.com>
>>>>>>>>> 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/
>>>>>>
>>>>>>
>>>>
>>>
>>
>
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
Posted by Jack Lund <ja...@stagrp.com>.
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:hostname>
</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 <ja...@stagrp.com>
>>>>>> 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 <ja...@stagrp.com>
>>>>>>>> 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/
>>>>>
>>>>>
>>>
>>
>
Re: [SPAM] - Re: Problems getting user exceptions to work - Found
word(s) check out in the Text body
Posted by Thom Hehl <he...@asset.com>.
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 <ja...@stagrp.com>
>>>>> 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 <ja...@stagrp.com>
>>>>>>> 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/
>>>>
>>>>
>>
>
Re: [SPAM] - Re: Problems getting user exceptions to work - Found
word(s) check out in the Text body
Posted by Jack Lund <ja...@stagrp.com>.
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 <ja...@stagrp.com>
>>>> 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 <ja...@stagrp.com>
>>>>>> 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/
>>>
>>>
>
Re: Problems getting user exceptions to work
Posted by Thom Hehl <he...@asset.com>.
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 <ja...@stagrp.com>
>>> 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 <ja...@stagrp.com>
>>>>> 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/
>>
>>
RE: Problems getting user exceptions to work
Posted by Jack Lund <ja...@stagrp.com>.
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 <ja...@stagrp.com>
>> 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 <ja...@stagrp.com>
>>>> 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/
>
>
RE: Problems getting user exceptions to work
Posted by Jarmo Doc <ja...@hotmail.com>.
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 <ja...@stagrp.com>
>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 <ja...@stagrp.com>
>>>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
>>
>>
>>_________________________________________________________________
>>Dont 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/
RE: Problems getting user exceptions to work
Posted by Jack Lund <ja...@stagrp.com>.
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 <ja...@stagrp.com>
>> 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/
>
>
RE: Problems getting user exceptions to work
Posted by Jarmo Doc <ja...@hotmail.com>.
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 <ja...@stagrp.com>
>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
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/