I've tried to throw in web service server side now
javax.xml.rpc.soap.SOAPFaultException .. Well, my JAX-RPC clients behave
way differently :-)
It seems, the Sun RI rethrows the SOAPFaultException. When I do use Axis
JAX-RPC implementation, it throws on the client side a RemoteException.
I do not know what the specs say about exceptions. Maybe I should study
the standars. Anyway, at the end I have to use the existing
implementations with their behaviors. Since my clients should be able to
work with "any" JAX-RPC implementation, I still think about implementing
my own mechanism to transfer exceptions.
cu
Merten
> -----Original Message-----
> From: Sels Wannes [mailto:Wannes.Sels_at_cronos.be]
> Sent: Tuesday, September 13, 2005 11:47 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Re: java.rmi.RemoteException vs.
> javax.xml.rpc.soap.SOAPFaultException
>
> Below is the code I use for creating soap faults. Just throw the
> SOAPFaultException and jaxrpc-ri will do the rest.
>
> /**
> * This method will convert an exception to a
> SOAPFaultException<br>
> * JAX-RPC RI will build a proper SOAP Fault from the
> SOAPFaultException
> * @param e Exception
> * @param log String
> * @return SOAPFaultException
> */
> public static SOAPFaultException makeSOAPFaultException (
> Exception
> e) {
> QName faultCode;
> String faultString;
> String faultActor;
> Detail faultDetail = null;
>
> faultCode = new
> QName("http://yournamespaceuri",e.getClass().getName());
> faultString = e.getMessage();
> faultActor = "Webservice name";
>
>
> try {
> MessageFactory mf = MessageFactory.newInstance();
> SOAPMessage msg = mf.createMessage();
> SOAPEnvelope env = msg.getSOAPPart().getEnvelope();
>
> faultDetail = msg
> .getSOAPBody()
> .addFault()
> .addDetail();
>
> Name faultDetailName = env.createName("StackTrace");
> DetailEntry dEntry =
> faultDetail.addDetailEntry(faultDetailName);
> StringWriter sw = new StringWriter();
> PrintWriter pw = new PrintWriter(sw);
> e.printStackTrace(pw);
> pw.flush(); sw.flush(); pw.close();
> String StackTrace = sw.toString();
> if (StackTrace != null && StackTrace != "")
> dEntry.addTextNode(sw.toString());
> }
> catch (SOAPException se) {
> //could not attach FaultDetail, can't fix that
> log.warn("Can't attach FaultDetail to
> SOAPFaultException",se);
> }
>
> return new
> SOAPFaultException(faultCode,faultString,faultActor,faultDetail);
> }
>
> -----Original Message-----
> From: Merten Schumann [mailto:Merten.Schumann_at_asg.com]
> Sent: dinsdag 13 september 2005 11:13
> 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