Can you try with 2.2.6-SNAPSHOT. I did some changes in this area in December.
That said, the "preferred" way to do this would be via a Sring AOP proxy around the the service that would handle the transactional part of this. You can look at our testcase config: http://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/jms/tx/jms_server_config.xml where we configure which exceptions should be propagated back to the client as a fault. Others would result in a rollback and retry. Dan On Wed December 30 2009 9:26:44 am cplin wrote: > I upgraded to 2.2.5 and see that it is no longer forking. This is perfect. > I'm looking to configure the retry functionality now. It looks like I have > everything configured, but it is not re-trying. It turns out that the > exceptions are captured and converted to faults that would normally go on > the response. Since the exception is no longer going up the stack, it never > triggers the re-try functionality. > > I know that one approach might be to create an interceptor that will handle > faults by throwing a unchecked exception. It looks like the CXF framework > will propagate any exceptions that occur during fault handling. I wanted to > see if you knew of another approach. Please let me know. > > Thanks, > Chih > > dkulp wrote: > > What version of CXF? > > > > The latest versions of CXF added a flag to the OneWayProcessorInterceptor > > to > > have it not fork off the thread. The JMSDestination sets that flag so > > things > > like the JMS transactions and such can work properly. > > > > Dan > > > > On Tue December 29 2009 10:51:24 am cplin wrote: > >> I'm trying to configure a JMS web service endpoint that is one-way. The > >> WSDL definition for the endpoint has a request message part and does > >> NOT have a response message part. However, I still want to be able to > >> leverage > >> the JMS re-try functionality. Digging into the CXF framework, I see > >> that the OneWayProcessorInterceptor will automatically spawn a new > >> thread (handles the request asynchronously) if the endpoint is one way. > >> Since it > >> is processed asynchronously, any exceptions (that would trigger retry > >> when > >> session transacted) would be part of the asynchronous thread, not the > >> JMS > >> handling thread, so the retry is never triggered. > >> > >> Is there a way to have a synchronous one-way (realizing that it is a bit > >> of > >> a contradiction) or is there a better approach with the CXF framework? > >> Ultimately, I'm just trying to leverage the JMS retry functionality for > >> a asynchronous web service operation that should be re-tried on failure. > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
