Would something like this be workable for you:
Don't expose your existing class as a web service. Instead, create another class as a wrapper. In that class, each operation would call a method in your existing class, something like:
public returntype WebVersion( parameters ) {
try {
return RealVersion(parameters); // where RealVersion is a method in your existing application
} catch (all the exceptions RealVersion might throw) {
.. .here construct an AxisFault with the detail string set to the information from
.. the actual exception, plus the name of the exception class.
and throw the AxisFault
}
}
Then the client-side code would catch the AxisFault, extract the information, and throw the appropriate kind of exception. That way, code outside the method that is invoking the SOAP service would get back exactly what it expects currently, including the exceptions.
Of course, I have no idea if this fits your situation. But it seems like it might be something to consider.
Steven Gollery
[EMAIL PROTECTED] wrote:
Can anyone explain clearly WHY developers are forced
to inherit from AxisFault class?
It is a huge problem with the AXIS product. The reality is that
lots of developers adding WEB Services to EXISTING applications.
And there is no way to change existing exceptions nor register custom
serializer/desirializer.
AXIS should not be so strict about exceptions. It should at least have
an INTERFACE instead of a class
Remember Java has only single inheritance - so it is "hard" to inherit
from two classes at the same time.
I think this requirement should be changed to implementation of the
AxisFault interface instead (or as an addition).
Gladly would hear an opinion from AxisFault implementation specialist...
In my case I becomes a showstopper to use AXIS at all, since it can't
properly serialize my CustomExeptions at the moment.
regards,
Ruslan Zenin
http://www.geocities.com/russ_zenin
-----Original Message-----
From: steve.l Sent: November 12, 2002 4:09 PM
To: steve.l; axis-user
Subject: Re: (Chained) Exceptions and beanMapping
Exceptions are special, as they go back over the wire as soapfaults, the
intent being better interop.
1. look at what the JAX-RPC spec has to say
2. look at AxisFault and how exceptions are handled.
You will probably have to sublcass AxisFault or java.rmi.RemoteException
for
anything to work
----- Original Message -----
From: "Hicks, SJC (Steve) " <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 12, 2002 9:35 AM
Subject: (Chained) Exceptions and beanMapping
I've created a custom exception in WSDL with some extra fields in it, generated the Java and deployed it all successfully (including settingup abeanMapping), but the extra fields don't seem to be serialized and deserialized to XML. The generated exception class has all the right constructors and allows me to set the fields in the object, but theyare notpassed in the SOAP message at all. The schema definition for theexceptionis: <schema ...> ... <complexType name="MyChainedException"> <sequence> <element name="chainedException" nillable="true" type="mce:MyChainedException"/> <element name="message" nillable="true" type="xsd:string"/> </sequence> </complexType> <element name="MyChainedException" nillable="true" type="tns1:MyChainedException"/> </schema> Is there something *extra* I need to do to force it to use the Bean (De)Serializer? Is it possible to do this at all for an exception?Anyoneelse had any success using chained exceptions with Axis? Cheers, Steve
