Raymond, Thanks for organizing this discussion much better. Responses inline...
On Jan 23, 2008 12:44 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, Scott. > > Thank you for bringing this issue up again for discussion. > > I think the topic is mostly about how to work with WSDL faults in Java. If > we start with a WSDL port type, the WSDL2Java mapping will generate the > corresponding Java exceptions to represent the WSDL faults. If we start with > a java interface, the Java2WSDL mapping will derive the fault definition > from the checked exception on the business methods. > > Let's look at various aspects in this area: > > 1) The model to represent the exception/fault metadata > > We have the following model today: > > DataType > physical ---- the exception class > logical --- DataType > physical --- the fault data class > logical --- the fault data logical type, for example, the XMLType > for the fault element > > I think it's OK. I think this could be OK, but let's also consider adding the exc->fault pattern to this model in some manner. More below... > 2) The Exception/Fault patterns (How does a java exception wrap/represent a > fault) > > There are a few important fault patterns: > * JAX-WS section 2.5 pattern (i.e. getFaultInfo() returns wrappered fault > with specific constructors) > * JAXWS section 3.7. It derives a WSDL fault from the plain Java exception > on the SEI. > * Axis2 pattern: It's similar to JAX-WS 2.5 pattern, but the method name is > getFaultMessage() > * Plain Java Exception: The exception itself has properties corresponding to > the fault data > * Other patterns such as JAX-RPC? > > The exception/fault pattern could be independent of the databinding of the > fault data. For example, we could use the JAX-WS 2.5 pattern for fault data > in SDO. We should replace the FAULT_ELEMENT with @WebFault. > > We can try to unify the fault wrapper exception pattern using JAX-WS. The > fault data can be represented using different databindings, such as SDO, > JAXB or POJO. > > When we introspect Java interfaces, we need to match the exceptions by > supported patterns and populate the DataType for the exceptions. So the introspection today is flawed in strictly tying the databinding of the fault to a single exception pattern. Someone might want to write an exception in the Axis2 pattern which wrappers an SDO. In today's framework you'd have to have an Axis2-pattern-SDO-fault exc handler. So I'm thinking we need to, for Java exceptions, figure out the exception->fault pattern first and then use that to figure out the type of the fault. Once we've figured that out the fault type we can simply do an introspectType(faultType, annotations) to figure out the databinding of the fault. The databinding of the fault is used to transform the fault from one databinding to another, however it should not be tied to the question of how to map between fault and exception. Since we already had to introspect to figure out that exc->fault pattern, let's save this information, i.e. save the fault pattern. It is that fault pattern then that should determine how to get from fault->exc and exc->fault. These functions are currently served by ExceptionHandler.createException() and ExceptionHandler.getFaultInfo(), respectively. Again, the ExceptionHandler is currently tied to a specific databinding when it should be tied to a fault pattern. Now.. you'll see in the patch I attached to TUSCANY-1206 a step towards implementing this. I'm not saying that the fields I added to DataType, 'exceptionHandler' and 'exceptionPhysical', represent the best solution. (In fact it's incomplete since I still have the ExceptionHandler tied to a DB). So if this is a good solution it should apply to WSDL intfs as well.. and I tried to take a step to integrate the WSDL introspector. I haven't looked at that code in awhile though so I'll leave it at that mention. > > 3) Service specific exception (user fault) vs. Protocol level exception > (system fault) > > There are two types of faults: > a) User fault: The service-specific fault decalred on the business > operation, for example, SymbolNotFound > b) System fault: The WS stack hits a system/procotol level problem > > Both faults could be seen in the SOAP messages, and we need to be able to > distinguish them. > > We use a FaultException to represent the fault data from different bindings > as the uniform wrapper. Different stack may use different exceptions for the > SOAP fault, for example, SOAPFaultException by JAXWS and AxisFault by Axis2. > > 4) The algorithm to match the fault data back to the corresponding java > exception > > We also need to refine the algorithm to map a fault data back to a Java > exception declared on the business method. It can be based on the fault > QName. If there is no match, we should wrap the fault into a > ServiceRuntimeException. > Thanks, > Raymond > > > > ----- Original Message ----- > From: "Scott Kurz" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, January 10, 2008 5:14 PM > Subject: Exception->Fault mapping > > > >A few months back, I wrote up a proposal for "decoupling the fault > > databinding from the way that the exception maps to a fault" > > which would among other things "get the exception handlers out of the > > introspection business." > > > > The mail is here: > > http://www.mail-archive.com/[email protected]/msg24973.html > > and I attached a patch to: > > https://issues.apache.org/jira/browse/TUSCANY-1206 > > > > Can we re-open this discussion? I know I may have missed some of > > the discussion in the meantime; I apologize and if so maybe someone > > wouldn't mind pointing me to that. > > > > Anyway at the time Raymond said it sounded like a good idea, but I > > don't think anything came of it. > > > > I know there's been some related work, e.g. Simon Nash's work on > > TUSCANY-1939, but to me it seems the issues I encountered still exist. > > > > This isn't just a question of elegance. One problem with using the > > ExceptionHandler.getFaultType() as an introspector can be seen by > > considering: > > > > public class MyExcMsg extends Exception { > > private int fault; > > public static QName FAULT_ELEMENT = new > > QName("http://blah","MyFault";); > > > > // The rest follows the JAX-WS Sec 2.5 pattern, > > > > So with the current code, the SDOExceptionHandler will say, "yes, I > > recognize this" and we'll set up SDO as the DB for the fault. But > > the DB should be "simple". > > > > And the bigger point I'm making is: the question of SDO, JAXB, or > > simple should be a question of what the fault looks like, not the > > pattern by which the exception > > maps to a fault. > > > > Scott > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
