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 - http://jroller.com/page/fate?entry=dodgy_benchmarks#comment2 - I could work my way through the xfire user archives, but I don't really have the time. -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
