Hello there,
in Tuscany SCA 1.6, it seems not to be possible to have a remote method that
declares
an abstract exception class in its interface, and access that method from a
remote node
over a webservice binding.
For example, say CurrencyConverterException is an abstract base class for my
checked
exceptions, and it has UnknownCurrencyException as an immediate concrete
subclass.
Then my service interface and implementation may look like this.
@Remotable
public interface CurrencyConverter
{
double getExchangeRate( String fromCurrencyCode, String toCurrencyCode )
throws CurrencyConverterException;
}
@Service(interfaces =
{ CurrencyConverter.class })
public class CurrencyConverterImpl implements CurrencyConverter
{
public double getExchangeRate( String fromCurrencyCode, String toCurrencyCode
) throws CurrencyConverterException
{
if( true )
{
throw new UnknownCurrencyException( "Unknown source currency: " +
fromCurrencyCode );
}
}
}
The client component has a reference to the CurrencyConverter service:
<sca:component name="ClientComponent">
<sca:reference name="converter">
<sca:binding.ws uri="http://localhost:8080/CurrencyConverter"/>
</sca:reference>
</sca:component>
When running the client in its own node, calling getExchangeRate on the
injected CurrencyConverter reference,
I will get a java.lang.InstantiationException in the class
org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper
Of course, the wsdl didn’t change a bit when I changed my service
implementation and made CurrencyConverterException abstract.
A normal JAX-WS Java client can continue to use the JAX-WS artefacts as it
always did and will not encounter this InstantiationException,
because it doesn’t even try to reconstruct a server side exception.
And of course, when using the webservice binding, the client should not have to
rely on technical
implementation details of the server (after all, the whole idea is they may be
implemented in different technologies). So
Tuscany shouldn’t try to give me the original exception, but the corresponding
web fault. Which would force the client
to use different exception handling code for a webservice than say for an RMI
binding. The technologies are just too different
to be handled in a uniform fashion.
We had this point before. I find it interesting that I keep running up against
it in the context of exceptions.
-- Sebastian
