cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject JAX-WS spec interpretation issue....
Date Wed, 30 Jan 2008 09:41:55 GMT

Could a couple of you check the JAX-WS spec and let me know what your 
interpretation of what is supposed to happen for a specific scenario?   

Scenario:
I'm calling a one way method on my client proxy
I have a Handler registered
That handler throws an exception, specifically a SOAPFaultException.  
(obviously on the outbound handleMessage call as there won't be an 
inbound)  Obviously, nothing makes it to the server.

What happens?   Does the exception make it back to the user or not?


In section 9.3.2.1 of the jaxws spec, it says for an exception during 
processing in a handler and no response is expected (one way):

Normal message processing stops, close is called on each previously 
invoked handler in the chain, the exception is dispatched (see section 
9.1.2.3).


To me, that means the exception is re-thrown back to the client to get 
caught.  That's what CXF is currently doing.  

The RI, however, swollows the exception.   It's gone.  Disappears into 
the ether someplace without any log or anything.   User never sees it 
and thus has no indication that their message never made it to the 
server.

Anyway, this is causing an issue with the 2.1 TCK and I'm trying to 
debate whether it's better to make CXF behave like the RI or start the 
whole process of challenging some tests.     Making it work like the RI 
is easy which would allow those tests to pass, but I'm pretty 
uncomfortable with just swollowing the exceptions.   I'm kind of leaning 
toward challenging the tests, but that's just not a fun process.   :-(   
That said, I already have to challenge a couple others, so what's a few 
more?   :-(


What are peoples thoughts?

-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message