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
>>
>
