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