OK I am going to revert my changes, add a config property to JMSConfiguration to optionally disable exception propagation.
The existing behavior will remain the default potential bugs and all. Cxf 3.0 won't need that property as that's the default anyway On 06/12/2014 3:45 AM, "Daniel Kulp" <[email protected]> wrote: > > Honestly, I have no idea on the transaction stuff in the JMS transport. > I’m really not sure of the use cases where it’s needed or working correctly > or as desired. > > For example, if the soap message isn’t valid and we cannot parse it, why > should it be rolled back and retried? We’re not going to be able to parse > it again next time either. If there are issues trying to send the > response back to the client, sure. I can see that. But most of the > others seem to cause more problems. > > > Dan > > > > On Dec 5, 2014, at 6:59 AM, Jason Pell <[email protected]> wrote: > > > > 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" <[email protected]> > > 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" <[email protected]> > >>> wrote: > >>> > >>> > >> -- > >> Christian Schneider > >> http://www.liquid-reality.de > >> > >> Open Source Architect > >> http://www.talend.com > >> > >> > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
