Dan, The HTTPConduit now uses an interposed MessageObserver on a standard HTTP Destination retreived from the DestinationFactory, so the client-side hard dependency on Jetty is now gone.
Of course, there may still be a client-side runtime dependency on Jetty if the client is configured to launch a decoupled response endpoint. So now that issue is put to bed, what other jars do you think can be removed from the minimal client-side footprint? /Eoghan > To be clear I'm not against using Jetty for the decoupled > cases. I just want to make sure its optional for people doing > very simple HTTP clients. Sure, 700K doesn't add much to the > several megabytes already required, although starting with > Java6 thats greatly reduced and then it plays a bigger > proportional role. Its a user perception issue. It adds > perceived complexity to CXF and adds clutter to people's lib/ > directories. Not everyone cares, but a lot of people do. I > figure I can cut out at least 7 required jars for users, > which would make it comparable to XFire I think. > > If there was a good reason to require Jetty, then I would be > OK with it, but after your message I don't see any real > technical reason why we should absolutely require it. To me > its like forcing our users to have activemq on the classpath > if they aren't using JMS. I think our policy should be to try > to create a minimum dependency footprint as reasonably > possible (obviously balancing the work needed). > > - Dan > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
