Issues with CXFServlet

["Glynn, Eoghan" <eo...@iona.com>]

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