Hi,
I checked in a fix under r629687. Major changes are:
1) Add a FaultExceptionMapper SPI as the generate contract to map between
service faults and java exceptions.
2) Implement it in JAXWSFaultExceptionMapper to honor the JAX-WS mapping
rules (The SCA spec says JAX-WS should be used for Java/WSDL mapping).
3) Remove the ExceptionHandler SPI from databinding framework as the mapping
is independent of databindings.
4) Change the WSDL2Java tool to generate Java exceptions for SDO using
JAX-WS @WebFault annotations.
5) Make sure unmappable faults are thrown as ServiceRuntimeExceptions.
Thanks,
Raymond
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, February 04, 2008 8:39 AM
Subject: Re: Exception->Fault mapping
Hi,
We had some explanations in the same thread before. Please see it below.
Simply speaking, when a SCA programmer works with Web Services, it uses
Java exceptions to represent WS faults. If she/he starts from WSDL,
WSDL2Java tool will generate the java exception from the WS fault. If
she/he starts with Java, Java2WSDL tool will generate the WS fault from
java exceptions. Different WS stacks have different patterns to map the
Java Exception and WS fault. We're trying to understand the patterns so
that databinding framework can help transform the fault data.
Thanks,
Raymond
<extracted from the previous note>
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.
</extracted>
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, February 02, 2008 11:13 PM
Subject: Re: Exception->Fault mapping
Raymond Feng wrote:
The binding-specific exception/fault mapping won't be exposed to the
programming model. I was proposing to make the mapping extensible so
that we can support multiple patterns without impacting the SCA
application code.
[snip]
Scott Kurz wrote:
I agree that this is where the mapping patterns are coming from.
But doesn't this undermine the
whole binding-independent programming model feature advertised by SCA?
Maybe it's just me, but I'm having trouble understanding what problem
we're trying to solve. Could one of you post an example illustrating the
issue in application developer terms?
My naive view is:
- binding-independent programming model sounds good!
- extensible mapping sounds scary, as an application developer will I
need to understand all these extensible mappings?
But again I'm probably missing something as I'm not really able to
understand what you're talking about, an example would help a lot.
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
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]
