cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: Http/s configuration Proposal
Date Thu, 31 May 2007 13:19:47 GMT
Sergey Beryozkin wrote:
> Hi Polar
>
> Finally I inderstand. This looks good. Changing the name of the bean name to a more neutral
name is also a good idea.
>
> Thanks, Sergey
>
> P.S I had to look into the English dictionary, 
> "To fret" is often used as a verb, meaning simply "to press down the string behind a
fret."
>
> This made me smile :-)
>
>   

Thanks Sergey, I do that all the time, on all my instruments except the 
fiddle (no frets). :-)

cheers,
-Polar
>   
>> Hi Sergey,
>>
>> Glad you brought this code up. I think this is what it should be:
>>
>> private static final String HTTP_LISTENER_NAME = "..."; <proposal still 
>> sought>
>>
>> private String listenerBeanName;
>> // The tlsParams will be null if not used.
>> private TLSServerParameters tlsParams =
>>            initTLSServerParameters();
>>     
>> .....
>>
>> public void configureBean(Object beanInstance) {
>>    String beanName = getBeanName(beanInstance);
>>    if (listenerBeanName.equals(beanName)
>>        && tlsParams != null)
>>    {
>>           // Is there a spring configuration?
>>           super.configureBean(beanInstance);
>>           // Make decision to override.
>>           if (isSetTLSParameters()) {
>>                LOG.fine("Overriding spring configuration of 
>> TLSParameters for " + listenerBeanName);
>>                 // maybe throw configuration exception?
>>           }
>>           // Override
>>           HTTPListenerConfigBean bean =
>>                   (HTTPListenerConfigBean)beanInstance;
>>           bean.setTLSParameters(tlsParams);
>>    }
>> }
>>
>> The big difference here, is that you call super.configureBean() first 
>> instead of last. Calling it
>> first makes you figure out if the application deployer actually 
>> configured it using Spring and
>> XML. Your configurer can choose to ignore that if you wish, because it's 
>> your code.
>>
>> Having the the super.configureBean() in order to get what you wanted 
>> forced the code in
>> CXF to ignore any call to setSslServer(). I believe that is wrong. CXF 
>> should do what you
>> tell it to, and you should be notified if it isn't going to work.
>>
>> The above setTLSParameters will work, regardless of whether the 
>> TLSParameters are set or not
>> because the configuration will not be "finalized" on the bean in 
>> question until after
>> Configurer. configureBean() is done.
>>
>>     
>>> Ok, given the above explanation, what is going to change for users 
>>> wishing to publish two providers serving different contexts on the 
>>> same 9090 port and configure the ssl setting of the port 
>>> programmatically? Sorry I don't understand you saying  no need to 
>>> write this expression per each endpoint.publish, only if once needs to 
>>> do it programmatically
>>>
>>>       
>> Nothing, unless people where doing trying to set two different keystores 
>> on two different destinations that
>> were on the same Port. Actually what was happening in that case, is that 
>> only the first configuration was
>> applicable. So, if Destination 1 wanted to publish on port 9000 and 
>> wanted to authenticate as "Alice" and
>> Destination 2 wanted to publish on port 9000 and wanted to authenticate 
>> as "Bob", Destination 2 was out
>> of luck in that case, and actually authentiicated as "Alice" without so 
>> much as a warning.
>>
>> Cheers,
>> -Polar
>>
>>     
>>> Thanks, Sergey
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>       
>>>> On May 30, 2007, at 11:58 AM, Sergey Beryozkin wrote:
>>>>
>>>>         
>>>>> With your proposal one needs to write this complex expression in  
>>>>> addition per every endpoint registration :
>>>>>
>>>>>           
>>>>>> ((JettyHTTPDestination)endpoint.getServer().getDestination()).
>>>>>>                    getJettyHTTPServerEngine 
>>>>>> ().setTLSServerParameters(parms);
>>>>>>             
>>>>> Does it mean that for https://localhost:9000/bar one can point to  
>>>>> one keystore for ex and for
>>>>> https://localhost:9000/foo one can point to another keystore ? What 

>>>>> is the point of calling
>>>>> setTLSServerParameters(parms); per every endpoint sharing the same  
>>>>> port ?
>>>>>           
>>>> No, one does not need to write this expression for each  
>>>> endpoint.publish.  You only need to do this if you want to configure  
>>>> the server engine programatically.  I think the point is, you should  
>>>> be doing that on the server engine instance directly, not indirectly  
>>>> through the Destination.
>>>>
>>>> Just to allay any fears, this is being done precisely to support the  
>>>> use case:
>>>>
>>>> Endpoint.publish("https://www.acme.com:9090/foo", ...);
>>>> Endpoint.publish("https://www.acme.com:9090/bar", ...);
>>>>
>>>> which is currently broken in CXF.
>>>>
>>>> I think we're in agreement here.
>>>>
>>>> -Fred 
>>>>         


Mime
View raw message