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 19:48:20 GMT


Well thats a different issue entirely, and trivial to solve by splitting
the HTTPTransportFactory into its constituent ConduitInitiator and
DestinationFactory components.

But it has no bearing what-so-ever on the conduit & decoupled
destination debate, as per your digression.

/Eoghan


> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com] 
> Sent: 04 April 2007 19:33
> To: cxf-dev@incubator.apache.org
> Subject: Re: Jetty dependency
> 
> I'm sorry, it's tied to the "http" implementation as the 
> HTTPTransportFactory generates the HTTPConduit and is also 
> hardcoded to spit out  JettyDesintations. That kind of ties 
> them both together.
> 
> -Polar
> 
> Glynn, Eoghan wrote:
> >  
> >
> >   
> >> -----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