cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: Jetty dependency
Date Wed, 04 Apr 2007 18:32:59 GMT
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