Hi Ryan,
well, for some reason I started with the interface and (let Axis
java2wsdl) generate the WSDL.
Having sent the message I thought "ups, you are in JAX-RPC mailing list,
you should describe what you mean with interoperability problems"
because within JAX-RPC world itself things seem to work to some extent.
I just found that obviously the transfer of exceptions in different
combinations of servers and clients doesn't work as I expected it or
better, as I would need it. The problem is, I have to transfer service
exceptions with a number of fields in a reliable way. For example, my
service exception has a line number if it's coming from a script and
all. So, we would end up with something like a complex type in the WSDL
for the fault.
Maybe I should again look at it, but I made the experience that complex
types in the WSDL crash a lot of existing (maybe outdated) SOAP stacks.
But I have to support the old stacks, like MS SOAP Toolkit ... And, if
there's something better supported in JAX-RPC/JAX-WS 2.0, well, my
target platform is J2EE 1.4, and there's JAX-RPC 1.1 the state of the
art. :-)
When I do transfer the exceptions "on my own" I think I will be more
successful, but I'm still trying and thinking ... :-)
Merten
> -----Original Message-----
> From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
> Sent: Tuesday, September 13, 2005 3:54 PM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: java.rmi.RemoteException vs.
> javax.xml.rpc.soap.SOAPFaultException
>
> 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
>
>
> ---------------------------------------------------------------------
> 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
>
>