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
