Folks, I've been looking into an issue with the CXFServlet not working as expected when a decoupled response endpoint is specified in the wsa:ReplyTo.
At first I thought it was simply a case of code being copied from JettyHTTPDestination to ServletDestination, and then not being kept up to date as the JettyHTTPDestination code evolved. Clearly it would have been better to abstract out the common logic into an abstract base class to avoid this, but in any case it turns out the issue is a bit more deep-seated. As it happens the servlet transport is incomplete, in the sense that it uses a null ConduitInitiator and thus cannot possibly participate in a decoupled MEP. Now I don't want to compound the original issue by duplicating the rt-transports-http ConduitInitiator logic in the rt-frontend-jaxws module. Neither does it seem very clean to make rt-frontend-jaxws depend on rt-transports-http so as to use the HTTP ConduitInitiator implementation directly (not least because this is entangled with the HTTP DestinationFactory). Anyway this got me thinking as to why the CXFServlet lives in the JAX-WS frontend in the first place. Surely the choice of frontend should be independent of the use of the servlet transport, e.g. shouldn't it be possible to say deploy in tomcat using the rt-frontend-simple instead? So I'm thinking the Servlet transport should ideally live in the rt-transport-http module instead. A cursory grep thru the servlet code suggests the only real dependency on JAX-WS is the hardcoding of the instantiation of org.apache.cxf.jaxws.EndpointImpl and the publish() call. But surely this could be done via reflection, with the class to instantiate and the publish method configured in the cxf-servlet.xml instead? Can anyone who's familiar with the motivation for entangling the servlet transport and JAX-WS comment on this? Cheers, Eoghan
