Hi,
I debugged the test case and found the code on the following stack is
problematic:
org.osoa.sca.ServiceRuntimeException: remote service exception, see nested
exception
at
org.apache.tuscany.sca.binding.jms.provider.AbstractMessageProcessor.extractPayloadFromJMSMessage(AbstractMessageProcessor.java:92)
at
org.apache.tuscany.sca.binding.jms.wireformat.jmstextxml.runtime.WireFormatJMSTextXMLReferenceInterceptor.invokeResponse(WireFormatJMSTextXMLReferenceInterceptor.java:107)
at
org.apache.tuscany.sca.binding.jms.wireformat.jmstextxml.runtime.WireFormatJMSTextXMLReferenceInterceptor.invoke(WireFormatJMSTextXMLReferenceInterceptor.java:82)
at
org.apache.tuscany.sca.binding.jms.provider.RRBJMSBindingInvoker.invoke(RRBJMSBindingInvoker.java:201)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:287)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy21.throwChecked(Unknown Source)
at
org.apache.tuscany.sca.binding.jms.ExceptionServiceClient.throwChecked(ExceptionServiceClient.java:38)
When the JMSMessage contains a fault (user exception), the
AbstractMessageProcessor.extractPayloadFromJMSMessage() method should not
throw a ServiceRuntimeException, instead it should call Message.setFaultBody
with the user exception extracted from the FaultException.
public Object extractPayloadFromJMSMessage(Message msg) {
try {
if (msg.getBooleanProperty(JMSBindingConstants.FAULT_PROPERTY))
{
// ----------------- [rfeng] This is
wrong ----------------------
throw new ServiceRuntimeException("remote service exception,
see nested exception", (Throwable)((ObjectMessage)msg).getObject());
}
} catch (JMSException e) {
throw new JMSBindingException(e);
}
return extractPayload(msg);
}
Thanks,
Raymond
From: ant elder
Sent: Wednesday, January 07, 2009 4:24 AM
To: [email protected]
Subject: Re: [1.4] Change in Exception handling behaviour for binding.jms
On Wed, Jan 7, 2009 at 11:12 AM, Dave Sowerby <[email protected]>
wrote:
Hey guys,
I'm trying to upgrade an application from Tuscany 1.3.2 to 1.4 RC4,
the application uses binding.jms and I've noticed a marked change in
behaviour for Exception handling - could someone tell me if this is
expected and if there is any means of getting a handle on the original
Exception?
Basically, the service throws a UserException with a message, but on
the client side I get the following Exception hierarchy:
org.osoa.sca.ServiceRuntimeException
-> org.osoa.sca.ServiceRuntimeException
-> java.lang.reflect.InvocationTargetException
-> org.apache.tuscany.sca.interfacedef.util.FaultException
Where the FaultException contains the original message from the
UserException.
Back in 1.3.2, for Exceptions the client would have a reconsituted
equivilant of the original Exception thrown.
Any guidance would be greatly appreciated,
Cheers,
Dave.
That sounds like http://issues.apache.org/jira/browse/TUSCANY-2593 which
sadly although marked as a blocker didn't get fixed in the 1.4 RC.
The problem is due to the way the DataTransformationInterceptor handles the
exception is different now so the way the JMS binding returns the service
exception doesn't get returned to the client as before. Tracing through the
code i can get it to DataTransformationInterceptor line 147 where the
sourceDataType gets set to
org.apache.tuscany.sca.interfacedef.util.FaultException which is what the
transform on line 159 produces so the original exception from the remote
service is lost.
There's quite a few FIXME comments around here in the
DataTransformationInterceptor so i'm not sure how this is supposed to work,
you'd think it must be common across all bindings - does any one know is
there a fixed way a binding can return an application checked exception
object and have the data binding framework just return that to the client?
...ant
