OK that helps, but also debugging there you see its too late at that point
as the service response message sent back from the service already contains
the wrong exception. Debugging on the service side this is the stack from
where it goes wrong:
Thread [ActiveMQ Session Task] (Suspended)
DataTransformationInterceptor.invoke(Message) line: 159
RuntimeWireInvoker.invoke(InvocationChain, Message, RuntimeWire) line:
129
RuntimeWireInvoker.invoke(RuntimeWire, Operation, Message) line: 104
RuntimeWireInvoker.invoke(Operation, Message) line: 98
RuntimeWireInvoker.invoke(Message) line: 86
WireFormatJMSTextXMLServiceInterceptor.invoke(Message) line: 68
OperationSelectorJMSDefaultServiceInterceptor.invoke(Message) line: 78
TransportServiceInterceptor.invoke(Message) line: 77
RuntimeWireImpl.invoke(Message) line: 149
RRBJMSBindingListener.invokeService(Message) line: 100
RRBJMSBindingListener.onMessage(Message) line: 76
ActiveMQMessageConsumer.dispatch(MessageDispatch) line: 1021
ActiveMQSessionExecutor.dispatch(MessageDispatch) line: 122
ActiveMQSessionExecutor.iterate() line: 192
PooledTaskRunner.runTask() line: 122
PooledTaskRunner$1.run() line: 43
ThreadPoolExecutor$Worker.runTask(Runnable) line: not available
ThreadPoolExecutor$Worker.run() line: not available
Thread.run() line: not available
Before DataTransformationInterceptor.invoke(Message) line: 159 is run the
"result" variable contains the correct original application exception and
thats what we'd like gets sent back to the clinet, but after
transformException is called at line 160 "newResult" is a
org.apache.tuscany.sca.interfacedef.util.FaultException instance and that is
whats returned to the client.
Is this related to the value of sourceFaultType which is:
sourceFaultType DataTypeImpl<L> (id=265)
dataBinding "org.apache.axiom.om.OMElement" (id=282)
genericType Class<T> (java.lang.Object) (id=9)
logical XMLType (id=298)
metaDataMap null
physical Class<T> (java.lang.Object) (id=9)
perhaps thats not correct with the way all the wireformats and databindings
are working now for JMS where really is just wanting to send back the
application exception in the response message?
...ant
On Wed, Jan 7, 2009 at 4:40 PM, Raymond Feng <[email protected]> wrote:
> 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
>
