Hi
On 11/21/06, Bill Burton <[EMAIL PROTECTED]> wrote:
Hello,
I've written a simple service that provides a way to lookup Person objects
by id or email address. The Person object just has some name and address
information. When a record is not found, I'm catching the runtime exception
from the Spring JDBC API, and rethrowing a checked exception which causes
XFire to generate a SOAP fault as follows:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema "
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>No record with id 000123005 was found by the findById
method!</faultstring>
<detail>
<RecordNotFoundException xmlns=" http://webservice.teds.pms"/>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Right now, I'm just using the default generated bindings in my Spring
applicationContext.xml
<bean name="PersonService"
class="org.codehaus.xfire.spring.ServiceBean">
<property name="serviceBean" ref="PersonServiceImpl"/>
<property name="serviceClass"
value="pms.teds.webservice.PersonService"/>
</bean>
but plan to switch to Aegis to have better control over the mapping for
other reasons.
Aegis is a default binding, so you are already using it:)
However, the person who's writing a C# .NET client to handle this complains
that it's hard to check for a fault whereas if I were to return an error
code and error text in my Person object, he would have no problem. As the
Person object is supposed to be a reflection of the database columns, I
really don't want to change it in this manner.
What are the best practices for generating an error such as "record not
found" or "database not available" cases?
I think that adding error codes to your data model object is a bad
idea. You should use exception ( SOAP fault ), as you do now.
Thanks for any assistance,
-Bill
--
Bill Burton < bburton ayht mail daht com>
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
