cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <ja...@pellcorp.com>
Subject Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Date Thu, 04 Dec 2014 22:13:44 GMT
I check that the exception cause is instanceof Exception and not propogate.
Otherwise the old functionality applies.
On 05/12/2014 8:41 AM, "Christian Schneider" <chris@die-schneider.net>
wrote:

> I think one thing to consider is handling of java.lang.Error. These are
> not of type Exception and not of type RuntimeException. As they are not
> expected a Rollback may be apropriate but I am not sure.
>
> As far as I can remember the reason why I did not implement a more
> sophisticated behaviour till now is that I never actually used transactions
> for Request/Reply.
> In one way messaging transactions are essential as the caller has to be
> sure that messages do not get lost.
> In request/reply there is always someone on the other side listening for
> the reply. If no reply comes he can and probably will retry. So there is
> much less pressure to use transactions at all.
>
> Christian
>
>
> On 04.12.2014 18:09, Jason Pell wrote:
>
>> Hi,
>>
>> I would like to change the existing behavior of JMS destination to NOT
>> rollback the transaction if a checked exception is encountered.
>>
>> https://issues.apache.org/jira/browse/CXF-6136
>>
>> Christian suggested I post an email to this list to give everyone an
>> opportunity to agree or disagree with my proposed changes.
>>
>> Currently if a transaction manager is registered (even just a JMS
>> transaction manager) and an exception is thrown by an impl method the JMS
>> message will be rolled back.
>>
>> There is currently no distinction made. Even if I throw a business soap
>> fault its still going to roll back the message.
>>
>> I would like to add code to JMS Destination to no longer propagate checked
>> exceptions which will result in the delivery of a soap fault response to
>> the JMS reply queue.
>>
>> Christian has suggested we could make this change without a backwards
>> compatible config entry in JMSConfiguration. I am happy to add a config
>> entry to maintain legacy behavior..
>>
>> Thoughts?
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message