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 Wed, 30 May 2007 17:22:58 GMT
Hi


here's the current Configurer code we have which is being executed before the providers even
get registered :

private static final String HTTP_LISTENER_NAME =

"org.apache.cxf.transport.http.JettyHTTPServerEngine";

private String listenerBeanName;

private SSLServerPolicy sslServerPolicy = new SSLServerPolicy();


public RepositoryListenerConfigurer(Properties props, String portValue) {

listenerBeanName = HTTP_LISTENER_NAME + '.' + portValue;

initServerPolicy(props);

}

// note, we're expecting JettyHttpServerEngine for a given port, we don't know anything else
about destination or any other details

and next the Configurer configureBean is called, we check if it's the JettyHttpServerEngine
and if yes, then we just set our ssl 
policy on it (won't have any problems id it will become TlsParameters, whatever) :

public void configureBean(Object beanInstance) {


String beanName = getBeanName(beanInstance);

if (listenerBeanName.equals(beanName)

&& sslServerPolicy.getKeystore() != null) {

HTTPListenerConfigBean bean =

(HTTPListenerConfigBean)beanInstance;

if (!bean.isSetSslServer()) {

bean.setSslServer(sslServerPolicy);

}

}


super.configureBean(beanInstance);


}

This is done just once, and once again, this is the JettyHttpServerEngine, not a destination
which we're configuring. This is a 
specific dedicated piece of code dealing with the configuration.

next we just do

> Endpoint.publish("https://www.acme.com:9090/foo", ...);

// do not wish to reconfigure anything just want to publish the provider instance


> Endpoint.publish("https://www.acme.com:9090/bar", ...);


and once again we do not do any reconfiguration here, the sole purpose is to just publish
providers. In fact that's really all we do 
as far as interacting with the CXF runtime is concerned (apart from having the providers code
for serving the requests)

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


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

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