cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: Http/s configuration Proposal
Date Thu, 31 May 2007 09:45:47 GMT
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 :-)


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message