users@jax-rpc.java.net

RE: Re: Is a JAX-RPC static stub client J2EE implementation specific?

From: Merten Schumann <Merten.Schumann_at_asg.com>
Date: Fri, 11 Jun 2004 15:30:16 +0200

Thank you, Kathy!

I've got still a question below ...

> >Another issue: I extended the sample to throw a custom exception
> >(created an exception class for this). When I do use a Dynamic Proxy
> >client, not my exception gets thrown in the cient (although
> I have the
> >class in the classpath), but a SOAPFaultException. In the static stub
> >client my exception appears as expected. So, in a Dynamic
> Proxy client,
> >do I have to search the SOAPFaultException for my exception
> on my own?
> >
> An application using a dynamic proxy client needs to be prepared for
> either of the following exceptions:
> -Service Specific Exception
> -SOAPFaultException
> -RemoteException
>
> So you would need to expect to see either of these when invoking a
> dynamic proxy client method.

I think the correct term "Service Specific Exception" means what I
called "custom exception" :-)

I mean this thing: is JAX-RPC itself "responsible" to (re)throw my
Service Specific Exception on the client side or not?

In the static stub client this worked fine, I got my MyException
rethrown in the client. In the Dynamic Proxy client (whose classes are,
in contrast to the static stub ones, portable as I've learned from you)
my Service Specific Exception was not rethrown but the plain SOAPFault
appeared. So I guess a Dynamic Proxy Client is not that powerful in
deserializing things according to WSDL as the Static Stub Client is.
It's absolutely ok for me, I just want to know, how things should be
according to definitions ...

If the Dynamic Proxy Client is not in a position to rethrow my
exception, I plan to transfer the exceptions on my own via an
appropriate web service entry point which just returns a string
representation of my exception. Then my framework will rethrow the
exception on the client side "by hand".

It's not that nice but will work and really is ok for me. The good thing
is, it makes the WSDL simpler (no SOAP faults) and that again relieves
in example my tests with Mozilla's web service implementation. I often
had to experience that my WSDLs couldn't get parsed by Mozilla when
there where complex SOAP/WSDL fault definitions.

Next week I will investigate that "stateless session bean" stuff. I'm
looking forward how (service specific) exceptions work there. Since this
stuff sits on top of JAX-RPC, I expect to find the same issue in a
Dynamic Proxy Client. We will see :)

Thank you!!!
   Merten

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net