cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject Re: HTTP dependency/decoupling issue
Date Mon, 05 Feb 2007 19:05:42 GMT

This is great news. I ran into the same issue and was just about to
write an email about HTTPConduit dependency on Jetty API. Btw, I
haven't looked at this in detail, but was that dependency necessary to
handle asynchronous requests? If so, would it be possible to plug in a
different server provider so that for example when running in an app
server, the app server container would be used instead?


On 2/5/07, Dan Diephouse <> wrote:
> Hi All,
> I'm working with someone who is looking to use CXF as a web service client.
> Currently we require a lot of jars[1], which is a topic for another thread.
> However there are two specific problems I see with things currently.
> 1. We require jetty to be on the classpath if people want to use a web
> service client. I'm very strongly against requiring Jetty to do simple HTTP
> clients. XFire already has people annoyed because of its dependency list
> [2], I would hate to imagine the the response if we required Jetty to do a
> simple web service client.
> I tried an initial fix of removing the inner classes from HTTPConduit which
> reference Jetty, but HTTPConduit has a dependency on ServerEngine which
> references AbstractHttpHandler, so its not quite so straightforward.
> 2. The HTTPConduit explicitly uses Jetty instead of depending on our
> Destination API. What if someone is deployed in a servlet environment and
> only port 80 is open? We should be We should be able to set up a decoupled
> listener on the servlet transport as well. Anyone know what the point is of
> explicitly referencing Jetty's APIs?
> --
> One solution would be to use the Destination API explicitly in the
> HTTPConduit instead of using the Jetty APIs. Another would be to of removing
> decoupling from the transport layer. I would appreciate it if others spoke
> up and gave their input as well though.
> I am of course for the latter. We have so much added complexity because of
> this (Decoupled* classes, ServerEngine references, extra Conduit APIs, the
> ugly Destination.getBackChannel(...), etc.) Its very feasible to do this and
> I still don't see what we have to lose by doing separating this all out. But
> I'm repeating myself...
> - Dan
> 1. Jars required currently:
> XmlSchema-1.1.jar
> activation-1.1.jar
> aopalliance-1.0.jar
> commons-logging-1.1.jar
> cxf-api-2.0-incubator-RC-SNAPSHOT.jar
> cxf-common-schemas-2.0-incubator-RC-SNAPSHOT.jar
> cxf-common-utilities-2.0-incubator-RC-SNAPSHOT.jar
> cxf-metacode-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-bindings-soap-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-core-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-databinding-jaxb-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-frontend-jaxws-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-transports-http-2.0-incubator-RC-SNAPSHOT.jar
> cxf-tools-common-2.0-incubator-RC-SNAPSHOT.jar
> jaxb-api-2.0.jar
> jaxb-impl-2.0.3.jar
> jaxb-xjc-2.0.3.jar
> jaxws-api-2.0.jar
> jsr181-api-1.0-MR1.jar
> jsr250-api-1.0.jar
> mail-1.4.jar
> org.mortbay.jetty-5.1.11.jar
> saaj-api-1.3.jar
> saaj-impl-1.3.jar
> spring-aop-2.0.jar
> spring-beans-2.0.jar
> spring-context-2.0.jar
> spring-core-2.0.jar
> stax-api-1.0.1.jar
> wsdl4j-1.6.1.jar
> wstx-asl-3.2.0.jar
> I'll be able to make SAAJ, Spring, and aopalliance optional as well with a
> little more tweaking...
> 2. One recent example of many -
> - I could work
> my way through the xfire user archives, but I don't really have the time.
> --
> Dan Diephouse
> Envoi Solutions
> |

View raw message