No problem. I will review the cxf 3 stuff early 2015 On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net> wrote:
> 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 > >
