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 Fri, 05 Dec 2014 11:59:04 GMT
I think I could probably live with no rollbacks at all even inside a
transaction. That is certainly more consistent than cxf 2.x.  Maybe we
don't even need to change anything in cxf 3.

Perhaps we can change cxf 2.x so it behaves same way. At least make it a
config option.

I could live with that as I agree with you the requestor can resend if
needed and its cleaner than the dead letter queue.

I might take another stab at disabling all exception propagation in JMS
Destination. I can then ignore the session matching issue and move on with
my life :-)

Be interested to get some background from Dan on why its there though...
On 05/12/2014 9:46 PM, "Christian Schneider" <>

> For request/ reply:
> If you have a transaction then the message will be rolled back if cxf
> dies. In all other cases cxf should send back a reply with the eventual
> exception as a soap fault.
> I think this behaviour is what you expect as a requestor.
> As there are always some cases where the requestor will get no reply or a
> fault the requestor always has to include some code to resend the request.
> I am not against using optional rollbacks but we have to make sure we do
> not create unwanted behaviour.
> Maybe we should have a switch for to decide if rollbacks should happen in
> request/reply. On the other hand I try to have as few switches as possible.
> Every thing that is done optionally increases test effort and makes it
> harder to document / explain how it works. So we should be sure it makes
> sense.
> Christian
> On 05.12.2014 11:29, Jason Pell wrote:
>> I would like the option of enabling roll backs for runtime exceptions in
>> cxf 3 when I eventually upgrade.  Does cxf 3 at least cater for a error in
>> middle of process where by the reply is never delivered but the request
>> has
>> disappeared so essentially there is no evidence of wother message. At
>> least
>> with the transaction even if it's just the spring JMS transaction manager
>> both messages will be delivered or neither will.
>> On 05/12/2014 8:44 PM, "Christian Schneider" <>
>> wrote:
> --
> Christian Schneider
> Open Source Architect

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