cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: HTTP dependency/decoupling issue
Date Wed, 07 Feb 2007 16:05:05 GMT
Thanks Eoghan!

1. Spring Jars - I would like to enhance our BusFactory to detect the
presence of spring and chose the appropriate Bus.
2. SAAJ Jars - For the simple frontend and dynamic client (which Paul just
submitted, more on this in another email), these shouldn't be needed. But
its built into the JAXBDataBinding if I'm not mistaken. I've been meaning to
give the databinding another round of cleanup anyway so I will do this as
part of that sweep.

Thats 7 jars right there :-) JSR-181 and JAX-WS API might be optional too
now that I think about it, I haven't checked though. And that brings our
minimum dependency set to... 10 jars! Still not exactly something to brag
about. Only so much one can do though.

- Dan

On 2/7/07, Glynn, Eoghan <> wrote:
> 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
> > |
> >

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message