You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2009/04/15 15:57:15 UTC
[jira] Created: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
--------------------------------------------------------------------------------------------------------
Key: TUSCANY-2967
URL: https://issues.apache.org/jira/browse/TUSCANY-2967
Project: Tuscany
Issue Type: Improvement
Components: Java SCA JMS Binding Extension
Reporter: Scott Kurz
For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710793#action_12710793 ]
Simon Laws commented on TUSCANY-2967:
-------------------------------------
I was looking through this today so some thoughts lest I forget.
I've been looking at this today and have checked in (r776381) enhancements to itest/jmsformat to test checked and unchecked exceptions for the various formats.
Our current code (excluding the jmsBytes change I committed at r775324) treats exceptions in the following way
checked/non-xml - object message
checked/xml - xml in text or bytes message
unchecked/non-xml - object message
unchecked/xml - object message
IIUC the objective of this JIRA is to make life easier for the non-Tuscany runtime while maintaining the functionality of the Tuscany runtime. We therefore have to consider three cases
Tuscany -> Tuscany
Tuscany -> non-Tuscany
non-Tuscany -> Tuscany
The proposal here is along the lines of...
checked/non-xml - ex.toString()
checked/xml - xml
unchecked/non-xml - ex.toString()
unchecked/xml - xml (invent some wrapper XML to hold ex.toString())
This would certainly make exception messages human readable but there is some devil in the detail of how we map a protocol like this to interface descriptions so that he Tuscany and non-Tuscany user isn't surprised. The next step is to add some non-Tuscany exception cases to itests and assess what the implications are.
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714361#action_12714361 ]
Simon Laws commented on TUSCANY-2967:
-------------------------------------
At revision: 779892 I backed out the trial change to bytes message format. All formats now return faults as JMS Object messages. Subject not getting much discussion here to at least the code is consistent while we decide what to do.
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder reassigned TUSCANY-2967:
----------------------------------
Assignee: ant elder
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703122#action_12703122 ]
Scott Kurz commented on TUSCANY-2967:
-------------------------------------
Good point Simon: performing an XML serialization of a RuntimeException would also be another piece of implementing my suggestion.
....
Going in a completely different direction, another approach would be to extend <binding.jms> (beyond even the OASIS spec) to allow configuration of a fault destination, separate from the response dest., which could have its own wireFormat. That might be a big enough step that we'd want to pose that to OASIS first... but I mention it thinking that if that is really the better solution we want, then it might not be worth trying to make the current state of affairs any better. Or it might...
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714424#action_12714424 ]
Scott Kurz commented on TUSCANY-2967:
-------------------------------------
Though we've put forth a few ideas, I still don't see a clearly better alternative to what we have today for the non-XML formats. While my original point was that sending an ObjectMessage is really odd, I've since come around to the view that if we can't go all the way towards implementing a "standard" that can be used by non-Tuscany on the other side, then there may be no point changing the non-xml behavior until perhaps we learn what we could do better.
For the unchecked/xml format, would it be too odd to use something similiar to what we will serialize with binding-ws-axis2 when an unchecked is thrown from the service side?
This is a SOAP envelope with SOAP Fault, e.g.
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>ORIGINAL_RUNTIME_EXC_MESSAGE</faultstring>
<detail/>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
I guess we could think about EXACTLY how to populate the <faultcode>, <faultstring> elements (for the former we could just pick something and for the latter we could try to use the original unchecked's message).
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws updated TUSCANY-2967:
--------------------------------
Attachment: 2967-3.patch
Hi Scott
I attached a hardcoded example where a non-checked exception is thrown in some arbitrary XML form. This is what it looks like...
<serviceRuntimeException xmlns=\"http://www.osoa.org/xmlns/sca/1.0\">
<message>...</message>
<stackTrace>...</stackTrace>
</serviceRuntimeException>
Is this the kind of thing you were thinking of? I'm not sure that this is a vast improvement over the object form other than it is at least human readable. They still won't know the schema for this though.
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
> Attachments: 2967-3.patch
>
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703130#action_12703130 ]
ant elder commented on TUSCANY-2967:
------------------------------------
Extending <binding.jms> to allow configuration of a fault destination with its own wireformat seems like a good approach to me.
and i agree with the comment about in that case it might not be worth trying to make the current state of affairs any better. We've made changes to the jms exception handling in several past Tuscany releases, might be nicer for our users to stop changing things till we really know what we want
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702313#action_12702313 ]
Simon Laws commented on TUSCANY-2967:
-------------------------------------
I suspect this comment applies to other wire formats (default and textXML) as there is code in the AbstractMessageProcessor that creates object messages for exceptions.
Where the contents of the message are XML should the unchecked faults, which won't have been turned into XML by the databinding framework be XMLified?
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2967) For binding.jms, consider a more
natural exception handling strategy for non-XML, non-Object wireFormats
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709959#action_12709959 ]
Simon Laws commented on TUSCANY-2967:
-------------------------------------
At revision: 775324 I've fixed up just jmsBytes to see if this is what we want. In the reference I catch the exception bytes being returned and throw them as a ServiceRuntimeException. The effect of this is that there are no checked exceptions. I.e. you can't just take the service Java interface and use if on the reference.
> For binding.jms, consider a more natural exception handling strategy for non-XML, non-Object wireFormats
> --------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2967
> URL: https://issues.apache.org/jira/browse/TUSCANY-2967
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Reporter: Scott Kurz
> Assignee: ant elder
>
> For the wF.jmsBytes, wF.jmsText cases, (when we're not dealing w/ JAX-WS exceptions/faults mapping to XML), it seems odd that we would give you back a TextMessage/BytesMessage for a normal response but an ObjectMessage for an exception (granted this was partly my idea).
> Should we instead do something like a toString() and convert an exception to a String we could place in either a BytesMessage or TextMessage? True, I think fidelity would suffer here and the app on the other end might not be able to reconstitute an exception instance matching the one thrown by the SCA service impl before it was turned into a toString by the SCA binding.jms.
> But I wonder if this is too unexpected.... if I'm expecting to receive a response TextMessage and get a ClassCastException because I get an ObjectMessage, that might seem really strange.
> Maybe this needs more discussion. I also admit I have no idea what other frameworks involving a map between RPC-ish invocations and JMS apps do with exceptions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.