[
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.
