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:[EMAIL PROTECTED] > Sent: 04 April 2007 19:33 > To: [email protected] > 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:[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. > >>> > >>> > >>> > >>> > >> > >
