On Thu, Feb 21, 2008 at 5:08 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> 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. > The reason i'd suggested to have a property to control this behaviour was for the case of a non-Tuscany client calling a Tuscany JMS service which expects a JMS text message response but if it gets a JMS Object message back containing an exception object then it might not be very obvious whats going on, at least with the simple exception string back in a text message its easyish to debug by looking in the message body. Not sure how useful this really is though so it also seems ok to me to not have the client property and just always do this if thats preferred. > > 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. > The only thing putting me off using the data binding framework is that i don't understand it and I've spent weeks trying to get things to work with it in the past without any success :-( ...ant > > Thanks, > Raymond > > ----- Original Message ----- > From: "ant elder (JIRA)" <tuscany-dev@ws.apache.org> > To: <tuscany-dev@ws.apache.org> > 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] > >
