howto return exceptions as soap faults

Hi,
i posted my problem before in the remoting forum but it was maybe the wrong place.
http://forum.springframework.org/showthread.php?t=25001
It would be nice if someone can help me.
Cheers,

Ingo

Quote:

---

Originally Posted by res1st

Hi,
i'm using a web service (xfire) to call my business methods. My business methods invoke DAOs to retrieve data.

I want to put execptions from my business logic and my DAOs into a "SOAP Fault" to give my clients some error feedback.
How can i do this?
Are there different ways to do it?

---

I'm not sure whether it is possible with XFire. Perhaps someone else can help you with this.

It is possible with Spring Web Services (the topic of this forum), however. Just as you would map an exception to an error page in your web.xml or -servlet.xml application context, you can do the same with Spring Web Services.

You do so by using the SoapFaultMappingExceptionResolver. In the download is a sample airline application which shows you how to wire this up. See http://springframework.cvs.sourcefor...e=text%2Fplain, at the bottom of the file.

Cheers,

You can create XFireFault by yourselft and setup on it all information you needed to pass to client.
Just create handler class with code to convert your custom exception to XFireFault and add it to faultHandlers list of xfire instnace.
Handler can look like this :
public class MyFaultHandler extends AbstractHandler {

public void invoke(MessageContext context) throws Exception {

Exception ex = (Exception) context.getProperty(DefaultFaultHandler.EXCEPTION) ;
if( ex instanceof XFireFault){
XFireFault w = (XFireFault)ex;
String infoForClient = convertMyException( w.getCause());
w.setMessage(infoForClient);

}
}
If you are using default config - sevices.xml you need just add following to it:
<xfire>
<faultHandlers>
<handler handlerClass="com.hp.webservices.handlers.MyFaultH andler"/>
</faultHandlers>
</xfire>

Thanks for your answers.

@poutsma
I'm still considering spring-ws but it isn't released yet as a stable version and i heard to much bad things. That's why i use xfire and switch maybe later to spring-ws. But good to know how it would work with spring-ws. Thank you.

@tomeks:
Do i understand it right?
The Business logic (and therefore DAO code) is invoked by xfire and that's why all exceptions can be cached by a xfire fault handler?

Cheers,

Ingo

Yes, all exceptions thrown by your service are catched and converted to XFireFault by service invoker, which is then serialized to SOAP fault.

Quote:

---

Originally Posted by res1st

i heard to much bad things.

---

Can you share with us the bad things that you heard?

Hi Routis,

i looked some weeks ago for web service technologies and found some bad blog entries and comments. Sorry, i didn't saved the links. But then i use goolge, i quickly find things like http://radio.weblogs.com/0112098/2005/11/23.html#a542.

I also didn't understand what's the advantage using Spring-WS for me. Top-down development sounds interesting, but it's more easy to create java interfaces/classes then wsdl documents, right?
At top-down the wsdl is constant. That's nice because ws-interfaces should be stable. But if i "freeze" my Java interfaces, the generated wsdl-file should also be constant. So, i stick with programming Java instead of WSDL.

I also looked in the documentation of Spring-WS and i wasn't very satisfied with that.

Cheers,

Ingo

Hi,

Let's start by saying that I'm perfectly fine with people using XFire: it is a fine solution for creating web services. In fact, I did some work on it in the past :-). In my opinion, XFire and Spring-WS are just two different ways of doing web services.

XFire is an integrated SOAP solution that is based on StAX, the fast Streaming API for XML. I would say that the focus of XFire lies on exposing Java classes as remote SOAP objects, using various XML bindings. For instance, it is really easy to expose a Spring-managed class as SOAP service using XFire, or to use JSR 181 annotations in it.

Spring-WS really consists of two modules. First, there is a module that abstracts over various XML marshalling toolkits. You can use this module in various surroundings, Web Services being just one of them. Second, there is the Web Service module itself, which focusses on doing document-driven, contract-first SOAP with a design based on Spring-MVC. If you are already using Spring-MVC, you will feel right at home, and can even reuse the validation and binding logic you wrote for your mvc app.

Given all this, allow me to "defend" Spring-WS against the points you mention.

Quote:

---

Originally Posted by res1st

i looked some weeks ago for web service technologies and found some bad blog entries and comments. Sorry, i didn't saved the links. But then i use goolge, i quickly find things like http://radio.weblogs.com/0112098/2005/11/23.html#a542.

---

Ah yes. You must understand that this blog entry was written three months before Spring-WS was released. James wrote this post as a response to some blog entry I wrote on the subject. At the time, I thought it would be nice to blog about the features of Spring-WS, just to give people some idea about what's in there. Of course, the post didn't reflect the entire picture, it was just a little intro. One of the differences with other SOAP stacks it neglected to mention was the fact that the O/X mapping module is totally separate from the WS functionality. I believe there are many people who just use spring-oxm, routis being one of them.

Quote:

---

Originally Posted by res1st

I also didn't understand what's the advantage using Spring-WS for me. Top-down development sounds interesting, but it's more easy to create java interfaces/classes then wsdl documents, right?
At top-down the wsdl is constant. That's nice because ws-interfaces should be stable. But if i "freeze" my Java interfaces, the generated wsdl-file should also be constant. So, i stick with programming Java instead of WSDL.

---

It's interesting to see that a lot of Web service programmers want to stick with Java, while actually the SOAP/XML that is sent across the wire is most important. Clients of your web service don't care whether you use Java or not, they care about the XML. Compare it to Hibernate: you wouldn't expect to use Hibernate without knowing at least a little SQL, would you? Spring-WS allows you to use any XML handling technique you want, even XML marshalling techniques (such as JAXB) if that suits you. It's all about choice.

Quote:

---

Originally Posted by res1st

I also looked in the documentation of Spring-WS and i wasn't very satisfied with that.

---

You are right here: the documentation isn't finished yet. While the chapter about XML marshalling is finished, the part about Web Services unfortunately isn't. I am working on it, however, and you can expect more documentation in the next release, planned for the end of this month.

Once again, I am perfectly fine with people using other WS solutions, I just wanted to elaborate on the differences.

Cheers,

BTW, Arjen, why your XFireExporter isn't part of spring dist ? :)

Quote:

---

Originally Posted by tomeks

BTW, Arjen, why your XFireExporter isn't part of spring dist ? :)

---

Why should it be? I really don't see any value, since you need the XFire jars anyway. People are complaining about the size of the Spring distribution enough as it is ;).