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 17:29:40 GMT
It appears that the get/setAuthorization for an HTTPDestination does 
nothing.
And this is confusing at best. What is this supposed to be? Is it 
supposed to be
a username and password a client is supposed to match?

In anycase, that kind of method can be superceeded by an interceptor 
that can
throw back a 401 to the client.

I'm going to remove it from the Destination configuration, and remove
the http-listener.xsd, HTTPListenerPolicy from http-conf.xsd, and remove
HTTPListenerConfigBean class, as ServerEngines will now be configured by
the factory configuration.

Cheers,
-Polar


Polar Humenn wrote:
> Ah, I thought the custom configurer was your desired approach.
>
> But I suppose if all you created the Custom Configurer for was to
> configure the JettyHTTPServerEngine, then I guess not!
>
> Cheers,
> -Polar
>
>
> Sergey Beryozkin wrote:
>> 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
View raw message