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: Jetty dependency
Date Wed, 04 Apr 2007 16:44:22 GMT
 

> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com] 
> Sent: 03 April 2007 21:26
> To: cxf-dev@incubator.apache.org
> 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.
> >
> >
> >   
> 
> 

Mime
View raw message