2013/2/19 Daniel Kulp <[email protected]>: > > On Feb 18, 2013, at 8:51 AM, Aki Yoshida <[email protected]> wrote: > >> Hi, >> you mean we should do the catch in unwind so that we can continue >> unwinding if this kind of exception is thrown during unwinding? >> >> I think that would makes sense. I saw today that the unwind method >> stops unwinding when a runtime exception is thrown. >> >> any comments from others? > > Well, to me, if we can, I'd have this throw and exception at startup time as > you are adding a feature that is incompatible with JAX-RS onto a JAX-RS > service. That's likely considered a configuration error and trapped at > startup. > > Dan >
Hi Dan, Yes. For this particular case, we can catch this condition at the startup. But I was wondering about how we should handle any unexpected runtime exception during unwinding. Whether to stop unwinding when hitting the first unexpected runtime exception like now or to ignore any runtime exception and continue unwinding the entire chain. I think the latter approach may be more robust in not potentially missing any cleanup code during unwinding. I don't think someone should exploit the current behavior to intentionally throw a runtime exception during unwinding and abort the unwinding. In that case, shouldn't we change the unwind behavior? In any case, we should decide on one or the other and explicitly document this behavior? thanks. aki > > > >> >> thanks. >> regards, aki >> >> 2013/2/18 XiLai Dai <[email protected]>: >>> Hi, >>> >>> There is a jaxrs server defined like this in spring: >>> <jaxrs:server id="orderRESTService" address="/rest" >>> xmlns:serviceNamespace="http://common.demo/" >>> serviceName="serviceNamespace:OrderService"> >>> <jaxrs:serviceBeans> >>> <ref bean="orderService" /> >>> </jaxrs:serviceBeans> >>> </jaxrs:server> >>> >>> It works well but will throw ClassCastException when adding wsa:addressing >>> feature into <jaxrs:server>: >>> <jaxrs:features> >>> <wsa:addressing >>> xmlns:wsa="http://cxf.apache.org/ws/addressing"/> >>> </jaxrs:features> >>> >>> The exception looks like: >>> Caused by: java.lang.ClassCastException: org.apache.cxf.message.XMLMessage >>> cannot be cast to org.apache.cxf.binding.soap.SoapMessage >>> at >>> org.apache.cxf.ws.addressing.soap.MAPCodec.handleFault(MAPCodec.java:78) >>> at >>> org.apache.cxf.phase.PhaseInterceptorChain.unwind(PhaseInterceptorChain.java:440) >>> at >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:306) >>> at >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) >>> at >>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) >>> at >>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218) >>> at >>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:163) >>> at >>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) >>> at >>> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158) >>> at >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243) >>> at >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:168) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) >>> at >>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219) >>> ... 32 more >>> >>> I know for REST service it makes no sense adding WS-Addressing support, but >>> maybe MAPCodec should be made some improvement to check in this case? >>> >>> Thanks! >>> Xilai > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
