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" <ch...@die-schneider.net>
wrote:
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
