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

Reply via email to