Hi Eoghan, On 2/5/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----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.
OK cool, I figured it was just for initial simplicity. 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
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
