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:[EMAIL PROTECTED] > Sent: 2007?4?4? 4:26 > To: [email protected] > 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. > > > > > > > >
