ant elder (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TUSCANY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570894#action_12570894 ]
ant elder commented on TUSCANY-2051:
------------------------------------
The suggested fix has already been implemented in the trunk code, but as pointed out, its not an optimal solution.
The JMS binding spec makes no mention of how to deal with faults or exceptions. For RPC style messaging we need a way to indicate that the response is either an application or system exception while invoking the service. Some messaging systems use a faultTo header on the request message similar to the existing replyTo header, but to add that would require a Tuscany specific change to the <binding.jms> scdl which doesn't seem ideal.
How about Tuscany sets a header on the request message to indicate faults should be returned, then if thats set and an exception occurs the exception gets returned in a JMS Object message along with a header indicating if its an application or system exception, then Tuscany can spot the exception when receiving the response and throw it to the client. If the fault header is not set on the request then the non-optimal fix of just returning the exception string is used.
Does that sound ok? Or any alternative suggestions?
Can you raise this as an OASIS issue? Sounds like we need some
clarification/guidance from the spec gurus here.
Simon
JMS binding: Exception while sending a FaultReply
-------------------------------------------------
Key: TUSCANY-2051
URL: https://issues.apache.org/jira/browse/TUSCANY-2051
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-1.1
Environment: Win XP
Reporter: Ph.Konradi
Class: JMSBindingListener.java
Method: public void onMessage(Message requestJMSMsg)
calling sendFaultReply(requestJMSMsg, e) fails
with the following exception:
Exception while processing message: java.lang.ClassCastException: org.apache.tuscany.sca.binding.jms.impl.JMSBindingException
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jms.impl.JMSBindingException
at
org.apache.tuscany.sca.binding.jms.provider.JMSMessageProcessorImpl.createXMLJMSMessage(JMSMessageProcessorImpl.java:140)
at
org.apache.tuscany.sca.binding.jms.provider.JMSMessageProcessorImpl.insertPayloadIntoJMSMessage(JMSMessageProcessorImpl.java:85)
at
org.apache.tuscany.sca.binding.jms.provider.JMSBindingListener.sendReply(JMSBindingListener.java:125)
at
org.apache.tuscany.sca.binding.jms.provider.JMSBindingListener.sendFaultReply(JMSBindingListener.java:152)
at
org.apache.tuscany.sca.binding.jms.provider.JMSBindingListener.onMessage(JMSBindingListener.java:65)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:854)
at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:99)
at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:166)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:117)
at
org.apache.activemq.thread.PooledTaskRunner.access$100(PooledTaskRunner.java:26)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:44)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
A quick, but not optimal, resolution would be:
change: sendFaultReply(requestJMSMsg, e)
to: sendFaultReply(requestJMSMsg, new Object[]{e})
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
