> -----Original Message----- > From: Polar Humenn [mailto:[EMAIL PROTECTED] > Sent: 03 April 2007 21:26 > To: [email protected] > Subject: Re: Jetty dependency > > I specifically think this is the right approach.
Me too. > Right now the HTTPConduit is tied to using JettyDestinations. How is the HTTPConduit tied to using JettyDestinations? It gets a decoupled Destination via whatever DestinationFactory happens to registered with the DestinationFactoryManager against http:// sytle URIs. Where's the hard jetty dependence in HTTPConduit? /Eoghan > 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. > > > > > > > >
