Ok, I followed the docs to the letter and extended FaultInfoException
instead of XFireFault. Still no luck. Then I took the BookService
example and it worked as it should. I changed it to use the embedded
server instead of the servlet and it still worked.
Then I added message logging to it, as described in [1] and now I saw
the same error as in my application, only an XFireRuntimeException on
the client. Turns out that adding a new DOMOutHandler as fault handler
prevents proper exception handling.
The requirement to extend from FaultInfoException is a bit too strict
for my taste. I am publishing the same services also via RMI remote
objects and am pulling an XFire dependency in. Also, it prevents me from
using any existing exception class hierarchy. Unless I can change its
root to FaultInfoException. Why can't I just implement a tagging
interface which serves as an indicator (and may even have a method
"Object getFaultInfo()". Or it could have been an annotation. And there
could be a default implementation of getFaultName (I tried to comment it
out as the fallback code in DefaultServiceConfiguration seems to allow
but that didn't work).
Also, what happens with any checked exception which has only the normal
detailmessage (in Throwable)? Do I have to subclass every
IllegalArgumentException etc. do add an empty getFaultInfo / standard
getFaultName to it? Can't an exception serve as its own detail bean,
provided it has getters/setters for the properties?
Regards
Werner
[1] http://xfire.codehaus.org/Logging
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
