Hi Merten,
Do you feel that using exceptions isn't very interoperable when you starting
with the Java service endpoint interface first and not the WSDL? In my case
I have started with the WSDL first and defined various faults within the
WSDL document. Then, wscompile generates the proper exceptions when it
generates the static stubs. I haven't run across any interoperability
problems yet. .NET seems to completely ignore the faults in the WSDL
document, and doesn't create a similar "exception" for them in the generated
.NET code. Have you run into any issues that I should know about?
Thanks,
Ryan
-----Original Message-----
From: Merten Schumann [mailto:Merten.Schumann_at_asg.com]
Sent: Tuesday, September 13, 2005 5:13 AM
To: users_at_jax-rpc.dev.java.net
Subject: Re: java.rmi.RemoteException vs.
javax.xml.rpc.soap.SOAPFaultException
Hm, I think I had bad experiences when declaring additional exeptions in
my web method signatures. In a way, I got the impression, it's the same
story as with these complex types for parameter and return values .. It
does not work well today in terms of interoperability .. At the end I
made my parameters and return values as simple as possible (Strings, for
the most part). And regarding exceptions, I thought the RemoteException
would be the appropriate place to transfer my service exception in a
wrapped fashion. Well, if I got you right, that's not what it's meant
for and I found it not to work properly.
Actually I think about implementing for my services my own mechanism to
transfer exceptions. The idea is, to store the original service
exception (in a serialized form) on the server and return an identifier
with the RemoteException message to the client. Then, the client could
invoke another web method to get the exception representation. Works
well for service specific exceptions. All other exceptions, which do not
contain my exception identifier, are really web exceptions and the
client will just present them as such :-)
Merten
> -----Original Message-----
> From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
> Sent: Tuesday, September 13, 2005 5:43 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: java.rmi.RemoteException vs.
> javax.xml.rpc.soap.SOAPFaultException
>
> Merten,
> RemoteExceptions were used mainly to mark methods as web methods. If
> you want to
> throw service specific exceptions, delare those additional
> exceptions as
> well in your method
> signature. Note that there are restrictions as to what such
> an exception
> can look like.
>
> I suspect that what you get on the client is due to different
> implementations interpretting
> the spec differently. Your best bet is to NOT throw
> RemoteExceptions if
> an error happens
> in your service, but rather service specif exceptions.
>
>
>
> Merten Schumann wrote:
>
> >Hello,
> >
> >when on my JAX-RPC web service server side an
> IllegalArgumentException
> >(which is a RuntimeException) gets thrown, in different
> combinations of
> >server (Sun AS, Tomcat with Axis, WebSphere) and clients
> (Sun JAX-RPC or
> >Axis JAX-RPC) the exception seems to be rethrown by the client side
> >differently. I saw the IllegalArgumentException wrapped in a
> >RemoteException as well as in a SOAPFaultException.
> >
> >My web service interface declares to throw RemoteException
> as required
> >by the spec. And so I do wrap custom exceptions in a RemoteException.
> >BTW: still I never saw the custom exception really wrapped in the
> >RemoteException at the client side, getCause() always returns null
> >there. :-(
> >
> >My question is, what about RuntimeExceptions? In the
> J2EE/JAX-RPC spec,
> >is it well defined how RuntimeExceptions should be
> transferred and what
> >the client SOAP stack should rethrow?
> >
> >Thanx a lot
> > 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
> >
> >
> >
>
> --
> - Doug
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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