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/02/12 17:07:59 UTC

[jira] Created: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over should serialize fault, not FaultException

Checked exceptions w/ default JMS wireFormat over <binding.jms> should serialize fault, not FaultException
----------------------------------------------------------------------------------------------------------

                 Key: TUSCANY-2845
                 URL: https://issues.apache.org/jira/browse/TUSCANY-2845
             Project: Tuscany
          Issue Type: Bug
            Reporter: Scott Kurz


I realize the spec doesn't spell this out, but I think the most natural mapping to say, what we do in <binding.ws>
would be to serialize the fault to XML and put it in a TextMessage, assuming that the other side can construct the appropriate
exception from the fault.

True this is very JAX-WS-ish, which a straight JMS programmer might not expect... but what else could we do, use java.lang.Exception somehow?

Today the checked exc seems to result in the throwing of FaultException, which will only work if Tuscany is on both sides.  



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over should serialize fault, not FaultException

Posted by Scott Kurz <sc...@gmail.com>.

I'd been thinking it might be more useful to use the message of the
innermost chained exception (which would more represent the "first failure")
than the outermost... but I didn't want to get too bogged down in that
detail... so I wrote leaving that up in the air.

Agreed that if we provide some useful info from the message of the chained
exception(s) then that would be good.

Thanks,
Scott

Re: [jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over should serialize fault, not FaultException

Posted by Simon Laws <si...@googlemail.com>.

On Sat, Feb 14, 2009 at 8:39 AM, ant elder (JIRA) <de...@tuscany.apache.org>wrote:

>
>    [
> https://issues.apache.org/jira/browse/TUSCANY-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673482#action_12673482]
>
> ant elder commented on TUSCANY-2845:
> ------------------------------------
>
> Just to make sure this is clear, the suggestion is for unchecked exceptions
> from a service exposed with a jms binding:
>
> - will be retuned with a JMS Object message
> - the Object message will contain a java.lang.RuntimeException
> - for SCA clients using a reference with a JMS binding that
> RuntimeException would be returned to the client as a
> ServiceRuntimeException
>
> If so that sounds ok to me.
>
> Not sure about the bit about maybe not even using the reusing a chained
> exception's "message", i can understand not returning the chained stacktrace
> but there's no harm in returning the message is there and it might make
> debugging easier?
>
>
>
> > Checked exceptions w/ default JMS wireFormat over <binding.jms> should
> serialize fault, not FaultException
> >
> ----------------------------------------------------------------------------------------------------------
> >
> >                 Key: TUSCANY-2845
> >                 URL: https://issues.apache.org/jira/browse/TUSCANY-2845
> >             Project: Tuscany
> >          Issue Type: Bug
> >          Components: Java SCA JMS Binding Extension
> >            Reporter: Scott Kurz
> >
> > I realize the spec doesn't spell this out, but I think the most natural
> mapping to say, what we do in <binding.ws>
> > would be to serialize the fault to XML and put it in a TextMessage,
> assuming that the other side can construct the appropriate
> > exception from the fault.
> > True this is very JAX-WS-ish, which a straight JMS programmer might not
> expect... but what else could we do, use java.lang.Exception somehow?
> > Today the checked exc seems to result in the throwing of FaultException,
> which will only work if Tuscany is on both sides.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Yep, Ok. As unchecked exceptions are not explicitly represented in the
interface I see your point. It makes sense to have a general way of dealing
with them. If there is information we can return that is generally
understandable by the client, e.g. string messages as apposed to SCA
specific exception types, we should try and return it.

Simon

Re: [jira] Commented: (TUSCANY-2845) Checked exceptions w/ default JMS wireFormat over should serialize fault, not FaultException

Posted by Scott Kurz <sc...@gmail.com>.

Simon,

Right, though I just wanted to clarify my proposal involved treating checked
and unchecked exceptions differently.

I like the idea of handling the checked exception with a wireFormat-specific
means (e.g. for object WF just serialize the exc into
an ObjectMessage and for dflt text/xml only serialize the fault obtained
from the exception per JAX-WS like we do for <binding.ws>).

For the unchecked exceptions, I just threw out there the idea that we
construct a java.lang.RuntimeException and send back an ObjectMessage.... in
all cases.

An alternative would be to come up with an equivalent representation of
RuntimeException for each wireFormat.

The latter would seem to be more in the spirit of defining specific
wireFormats for specific services.   My suggestion has the advantage of
there being less to document (and maybe less to code) to explain how this
all works.

Not sure...

Scott

On Fri, Feb 13, 2009 at 12:06 PM, Simon Laws <si...@googlemail.com>wrote:

>
>>
>> Without a spec, I can't think of a better thing to do for now for throwing
>> unchecked exceptions over a <binding.jms> service
>> than to always use an ObjectMessage, but I think we should do it in a way
>> such that we don't require any SCA or Tuscany code on the client.
>
>
> At the moment the chosen wireFormat has a bearing on the format of the
> exception as it's thrown across the (JMS) wire. So in the default/textXML
> case the exception is passed back over the wire as an XML document. With
> Ant's latest changes it's arguably better than it was before. We pass back a
> Text message with the exception XML in it. Intead of a Object message with
> and Axiom object in it.
>
> In the case of Object format you would expect the exception to be in an
> Object message. If you get into more esoteric wire formats I guess you have
> to document how exceptions will be passed so that you can pick them up in
> the non-SCA case.
>
> The alternative is to always throw exceptions in the same format.
>
>
>>
>>
>> To do this, we're going to have to accept that we're going to accept that
>> we'll lose the chain of exceptions we may have in the service-side container
>> and simply throw a new java.lang.RuntimeException (and not
>> ServiceRuntimeException), possibly reusing a chained exception's "message"
>> (or maybe not even).
>>
>> So the non-SCA programming model for dealing with this becomes:
>>  // listen for a response
>>  if (responseMsg is ObjectMessage)
>>     look for RuntimeException in message and deal with this somehow
>>  else
>>     handle normally the message of=f expected message type (depending on
>> wireFormat)
>
>
> We would need to look inside the return message to see what is in there as
> it might or might not be an exception.
>
>
>>
>>
>> And for an SCA reference we would have to do the same for every wireFormat
>> on the reference side, (and "dealing with" the RuntimeExc
>> would translate into throwing ServiceRuntimeException).
>>
>> Thoughts?
>>
>>
>>
>