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 15:19:32 GMT
Hi

>> BusFactory.getDefaultBus().getExtension(JettyHTTPServerEngineFactory.cla
>> ss).setTLSParametersForPort(1234, tlsParameters);

This looks compact and simple as far as the programmatic port configuration is concerned.

With this proposal will there be a need to register a custom Configurer, the way we do it
now ?
I'm assuming it will be an alternative option to writing the code above ? Not that we'd prefer
creating a custom Configurer given the simplicty of the above code  but just want to understand
what the options are.

Thanks, Sergey


> Would this approach be a better way to configure JettyHTTPServerEngines
> using Spring? We configure the JettyHTTPServerEngineFactory instead?
> 
>   Sergey?
> 
> Since, we are having a problem coming up with a good Qname for a 
> ServerEngine
> because it will be completely generic (not associated with any WebPort, 
> etc, like
> the destinations are) yet still have to be distinguished by a port 
> number, we
> could just have:
> 
> <jettyServerEngineFactory bus="cxf">
>     <tlsParameters port="1234">
>            .....
>     </tlsParameters>
>     <tlsParameters port="4999">
>          ....
>     </tlsParameters>
> </jettyServerEngineFactory>
> 
> 
> How about it? I can whip that up.
> Cheers,
> -Polar
> 
> 
> Polar Humenn wrote:
>> Good Idea Eoghan, that eliminates the need to retrieve/create in a 
>> public api.
>> It's kind of logical that if you change the parameters after the thing 
>> is created
>> then you should expect it won't have an effect until the engine is 
>> shutdown
>> and recreated.
>>
>> Cheers,
>> -Polar
>>
>> Glynn, Eoghan wrote:
>>> How about just providing an API to allow the overriding programmatic
>>> TLSServerParameters to be set on the JettyHTTPServerEngineFactory
>>> *without* requiring that the app go away and actually create a
>>> JettyHTTPServerEngine explicitly.
>>>
>>> For example:
>>>
>>>  
>>> BusFactory.getDefaultBus().getExtension(JettyHTTPServerEngineFactory.cla
>>> ss).setTLSParametersForPort(1234, tlsParameters);
>>>
>>> These parameters would then be used by the JettyHTTPServerEngineFactory
>>> if and when a new JettyHTTPServerEngine is required for that port.
>>>
>>> Cheers,
>>> Eoghan
>>>
>>>  
>>>> -----Original Message-----
>>>> From: Polar Humenn [mailto:phumenn@iona.com] Sent: 31 May 2007 14:38
>>>> To: cxf-dev@incubator.apache.org
>>>> Subject: Re: Http/s configuration Proposal
>>>>
>>>> There is somewhat of a problem with the proposal as it stands, which 
>>>> is first initialization of the JettyServerEngine.
>>>>
>>>> This beast looks like it definitely stands on its own and things 
>>>> attach to it, namely destinations by port number.
>>>>
>>>> The problem with
>>>>    ((JettyHTTPDestination)endpoint.getDestination()).
>>>>             getJettyHTTPServerEngine().setTLSParameters().
>>>>
>>>> is that the "getJettyHTTPServerEngine()" must initially create 
>>>> and"configure"
>>>> a JettyHTTPServerEngine before it returns one. Then, as above 
>>>> states, it gets "reconfigured", which could be a potential problem.
>>>>
>>>> I suggest that for the API, that we place the 
>>>> JettyHTTPServerEngineFactory directly on the Bus.
>>>>
>>>> This will allow users to programatically be able to set the 
>>>> TLSServerParameters directly on the server, and then the address is 
>>>> picked up by the destination.
>>>>
>>>> JettyHTTPServerEngineFactory factory =
>>>>     BusFactory.getDefaultBus().getExtension(JettyHTTPServerEngineF
>>>> actory.class);
>>>>
>>>> assert factory != null;
>>>>
>>>> int port = 1234;
>>>>
>>>> JettyHTTPServerEngine engine = factory.retrieveEngine(port); if 
>>>> (engine == null) {
>>>>        engine = factory.createEngine(port, tlsParameters); }
>>>>
>>>> Endpoint.publish("https://localhost:1234/foo", ....); 
>>>> Endpoint.publish("https://localhost:1234/bar", ....);
>>>>
>>>>
>>>> For programs that do not create the JettyHTTPServerEngine 
>>>> programatically may have it done via spring, and/or your special 
>>>> Configurer without incident. The Destination will create a server 
>>>> engine if needed, as it does now. The only problem will be if the 
>>>> user asks for "https" and doesn't configure the engine beforehand, 
>>>> programatically or through spring.
>>>>
>>>> The only other concern, is that this approach is implementation 
>>>> specific to using the HTTP_JETTY module, but then again, that was 
>>>> the case all along.
>>>>
>>>> Does anybody disagree with this approach for configuring Ports, with 
>>>> TLS or not?
>>>>
>>>> Cheers,
>>>> -Polar
>>>>
>>>>
>>>>     
>>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message