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