> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 05 February 2007 18:53 > To: [email protected] > Subject: HTTP dependency/decoupling issue > > 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?
Well the reason I did that way is simple. The logic required to handle an incoming HTTP message, *prior* to the MessageObserver.onMessage() being notified, is subtly different depending on whether its an incoming request or decoupled response. Different message properties need to be set for example, and a different strategy is required in order to associate an Exchange with the incoming message (in decoupled case we need to create temporary disposable Exchange which is then later replaced by the real Exchange once the response is correlated with the corresponding request). So simply getting a Destination from the current HTTP DestinationFactory wouldn't have given me exactly what I wanted. So to achieve this difference in handling the incoming HTTP message, the most convenient thing was to register a specialized Jetty handler for decoupled responses, given that we were already using Jetty as our primary standalone HTTP listener. Now on reflection, I reckon I could have achieved the same thing by getting a HTTP Destination from the current factory, combined with a wrapper MessageObserver that set and unset properties, exchange, content etc. appropriately before calling on through to the real MessageObserver (the ClientImpl in the decoupled case). I'll look at changing it around to work this way. However can you expand on what exactly the objection is to Jetty on the client-side? Lets deal with the standalone client app and servlet container cases separately. In the stand-alone client app case, is it the size of the Jetty jar that's the problem? Note there are other far larger jars already required on the client side. We could stick in a light-weight alternative HTTP DestinationFactory based on say nanoHTTP, though I'm unconvinced that shaving off a few hundred kb off the client foot-print is worth the trouble. Or is the issue just that for a non-decoupled client, we shouldn't have a requirement for Jetty, but for a decoupled client the footprint of Jetty is fine? In the client deployed in tomcat use-case, I think we can accommodate this with the changes I mention above, as long as the configured decoupled response endpoint URI is chosen carefully not to line up with the tomcat HTTP connector port and the url-pattern specified in the web.xml (with say "/decoupled response" appended). /Eoghan > -- > > 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 >
