cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Jetty dependency
Date Wed, 04 Apr 2007 17:58:11 GMT

Actually, I already have this 80% done (I'm running into some of the same 
issues the Geronimo folks are running into related to this).   Thus, 
I'll just finish it up and get it committed.

Dan


On Tuesday 03 April 2007 22:36, Liu, Jervis wrote:
> Hi, if there is no further objection, I will create a jira task to
> separate http into two modules. I will be working on this probably end
> of this week or early next week.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007?4?4? 4:26
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Jetty dependency
> >
> >
> > I specifically think this is the right approach. Right now the
> > HTTPConduit is tied to using JettyDestinations. I don't even
> > see why you
> > need Jetty if you a) don't have any decouple endpoints, or you
> > aren't doing any servers at all.
> >
> > This could come back to the argument that the conduit shouldn't be
> > managing decoupled endpoints, but I digress.
> >
> > Cheers,
> > -Polar
> >
> > Daniel Kulp wrote:
> > > On Tuesday 03 April 2007 13:06, Liu, Jervis wrote:
> > >>> So lets say we now have two DestinationFactory
> > >>> implementations available in the classpath, one is
> > >>> JettyDestinationFactory  another one is
> > >>> GeronimoDestinationFactory, how do we control which one gets
> > >>> picked up by bus? As long as we still ship
> > >>> JettyDestinationFactory with the distribution and have its
> > >>> cxf-extension-http.xml in the classpath,
> > >>> JettyDestinationFactory will get loaded. We cant say in order
> > >>> to load your own DestinationFactory implementation, you need
> > >>> to remove JettyDestinationFactory's cxf-extension-http.xml
> > >>> from classpath then add your DestinationFactory' extension
> > >>> file into classpath. We will need sth else...
> > >>
> > >> To answer my own question, do you mean we seperate current
> > >> cxf-rt-transports-http-2.0-incubator-RC-SNAPSHOT.jar into two
> > >> jars, one is for basic http support stuff, one is for Jetty, lets
> > >> call it cxf-http-jetty.jar here. So if users do not want to use
> > >> jetty, they just don't put cxf-http-jetty jar into their
> > >> classpath. So
> >
> > this works
> >
> > >> I believe, the only issue is that users wont be able to use that
> > >> single cxf-bundle jar ( I believe we do want  Jetty stuff in our
> > >> cxf-bundle jar as this is our default support for http, don't
> > >> we?)
> > >
> > > Right.  That's exactly what I mean.   For "normal" users
> >
> > using the bundle
> >
> > > jar, no impact.    However, for the embedded developers
> >
> > using the full
> >
> > > module approach (expecially those using Maven), they can
> >
> > selectively not
> >
> > > include the Jetty stuff if they don't want/need it.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message