cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <>
Subject Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Date Thu, 04 Dec 2014 22:26:04 GMT
Very annoyed with myself that I did not check the transaction support for
request response till now. Was on my list of todos. Now I am going to have
to depend on 2.7.15 snapahot.

I need guaranteed delivery even for request response as my client is not
expecting to have to retry and the message needs to survive a server crash
or db issue.

I am not going to use xa transactions though. Will be enough to use good
old jms transaction manager support.
On 05/12/2014 9:13 AM, "Jason Pell" <> wrote:

> 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" <>
> 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.
>>> 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
>> Open Source Architect

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