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
