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 14:30:34 GMT
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
View raw message