Some comments:
1) For RPC style, any failures on the service side should produce a fault
JMS response message. The client side will be blocked if there is no
response. Maybe we don't need a JMS property to mandate this behavior.
2) +1 to have a tuscany-defined JMS property to indicate if the JMS message
represents a fault or a normal response if the back-end is a SCA service
with JMS binding. The differentiation of system fault or user fault is
tricky, I'll start another thread to discuss it in wider scope.
3) If the back-end is a legacy JMS application, then we need some way to
detect if the JMS response is a fault or normal reply.
4) JMSBinding could use the databinding framework to transform the fault
data into its expected format and then marshal/unmarshal it over the JMS
transport. This is similar with Web Service binding. Since JMS Message is a
weakly-typed messaging structure, we can explore if we should be able to
express the databinding (like the MIME type) to package the payload.
Thanks,
Raymond
----- Original Message -----
From: "ant elder (JIRA)" <[email protected]>
To: <[email protected]>
Sent: Wednesday, February 20, 2008 3:59 PM
Subject: [jira] Commented: (TUSCANY-2051) JMS binding: Exception while
sending a FaultReply
[
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?
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})
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
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]
