Fred,
Remember CXF supports pluggable frontends, and thus interceptors should in general be independent of the frontend that the user happens to choose ... i.e. your interceptors should work just as well regardless of whether JAX-WS or the simple frontend or whatever is being used at the application level. So the short answer is that throwing the javax.xml.ws.* exceptions from an arbitrary interceptor is probably not a great idea. Someone writing a simple-frontend-based app is likely to be unpleasantly surprised if their inovcation barfs back a javax.xml.ws.ProtocolException for example. The exceptional case is of course when the interceptor is known only ever to be used if JAX-WS is in play. And we do have a bunch of those (for example the interceptors that wrap the JAX-WS Handler chains). I don't think there really is a direct analogue for CORBA::SystemExceptions in CXF, in the sense that interceptors are free to throw any unchecked exception type. Similarly I don't think there's really an equivalent of CORBA::UserException. Depends again on the frontend, but for JAX-WS at least, a <wsdl:fault> simply maps onto a direct subclass of Exception ... i.e. there's no common base class for all exception types generated from WSDL faults. But maybe we do need to clearly call out any non-binding conventions we expect interceptor impls to follow wrt to exception types. For example the throwing of org.apache.cxf.interceptor.Fault that you mention. Whether we'd go further and harden the convention by making Fault a checked exception, so that putting it in the signature of Interceptor.handleMessage() actually means something, and then treat any unchecked exception thrown from Interceptor.handleMessage() as a "nasty surprise" as opposed to an contingency envisaged by the design ... well, that's a question on which no doubt there would be robust discussion. But its late and I've had my fill of Java coding-style jihad for one day :) Cheers, Eoghan > -----Original Message----- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: 04 April 2007 20:24 > To: [email protected] > Subject: A bit confused by exceptions > > Looking at the JAX-WS 2.0 spec: > > {{{ > The following standard exceptions are defined by JAX-WS. > > ''javax.xml.ws.WebServiceException'' A runtime exception that > is thrown by methods in JAX-WS APIs when errors occur during > local processing. > > ''javax.xml.ws.ProtocolException'' A base class for > exceptions related to a specific protocol binding. > Subclasses are used to communicate protocol level fault > information to clients and may be used by a service > implementation to control the protocol specific fault representation. > > ''javax.xml.ws.soap.SOAPFaultException'' A subclass of > ProtocolException, may be used to carry SOAP specific information. > > ''javax.xml.ws.http.HTTPException'' A subclass of > ProtocolException, may be used to carry HTTP specific information. > }}} > > Are these recommended exception types, when writing CXF applications? > > The reason I ask is this. My interceptors are designed to > raise org.apache.cxf.interceptor.Fault exteptions under error > conditions, > as this seems to be the prescribed behavior. Why do I think this? > Not sure. I think I read it somewhere. (Sorry I can't be > more specific). These exceptions are being thrown from > server-side interceptors. > > What I'm finding is, my client is getting exceptions of type > org.apache.cxf.binding.soap.SoapFault. Tracing the > inheritance tree, we basically seem to have: > > + java.lang.RuntimeException > | > + org.apache.cxf.common.i18n.UncheckedException > | > + org.apache.cxf.interceptor.Fault > | > + org.apache.cxf.binding.soap.SoapFault > > No javax.ws.xml.* to be found. Am I throwing the wrong types > from my interceptors? Is there any guidance for what to do > here? (Apologies for the naivete of the question) > > As an aside, is there an analogue to CORBA::SystemException > and CORBA::UserException (and their descendents) in jax-ws? > The somewhat nice thing about exceptions of that type is that > it is a catch-all for problems with the plumbing, as opposed > to problems with the application, which can form a convenient > switch in a lot of code. > > PS> It's a shame exceptions aren't interfaces in Java. (It's also a > shame Java doesn't support multiple inheritance, but I won't > ignite another holy war! :) > > -Fred >
