Re: Why is the servlet in the jax-ws frontend - I believe this is because it supports exposing JAX-WS endpoints via an XML configuration file. This could be moved into the HTTP module and we could add some publisher class which is used via reflection. I think it hasn't been high enough on anyone's priority list to care about yet.
Regarding the decoupled case - It does seem the code is wrong. However, seeing that we will have 4 different HTTP transports in the end (jetty, asyncweb, servlet, geronimo), can't we please please please just move this decoupling logic into WS-A and add a method which allows the layer above to see if its policy compatible? As I've outlined before I think this is a better approach as: 1. Policy is enforced by the layer using the transport, not by the transport itself. So this approach would be more semantically correct. 2. The current getBackChannel() method is really performing two different functions. AFAIK there isn't a case where you have both a non null in message and partial response in the same invocation. 3. It is really confusing for transport writers currently (It is very hard to explain this method to users who are not familiar with RM) 4. It builds in RM semantics into our transport layer. Our transport layer should be flexible enough that RM can use it without special allowances. 5. There is less code duplication Proposals: 1. Add "boolean isEncrypted()" to Conduit interface. Pros: simplest possible thing to support our current needs. Cons: It could be pretty worthless encryption, so that doesn't say much. 2. Create a list of things we would need to know about a transport (is it encrypted, encryption type, etc) and add a Conduit.getProtection() which returns this information. Thoughts? - Dan On 12/22/06, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
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
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
