cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: HTTP dependency/decoupling issue
Date Wed, 07 Feb 2007 12:00:02 GMT

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
> 

Mime
View raw message