cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Jetty dependency
Date Wed, 04 Apr 2007 02:36:59 GMT
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.
> >
> >
> >   
> 
> 

Mime
View raw message