You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Polar Humenn <ph...@iona.com> on 2007/05/30 17:35:38 UTC
Http/s configuration Proposal
Greetings,
As you know there as been some work done to correct/enhance the use of
SSL/TLS
in the Http modules. CXF-661, CXF-666, CXF-672.
In that effort, a significant change in the parameters for SSL/TLS was
required. It
added a new
setTLSServerParameters(TLSServerParameters params)
call in which the TLSServerParameters is more in-line with the JSSE,
which is
used exclusively for SSL/TLS transports. However, I kept the
setSSLServer(SSLServerPolicy policy)
call in order to maintain and not to break any existing configurations both
Spring and programmatic. Analogous stuff was done for the client side.
However, I have deprecated "setSSLServer()" and everything else
internally that is related
to it. That approach seems to be working. There seem to be some
complaints about the
"deprecation" compiler warnings.
The question is for version 2.0, since we are moving from 1.x, do we
want to eliminate the
old configuration all together? My feeling and some consensus relayed to
me is "yes".
I propose that we do remove the "setSslServer()" and "setSslClient()"
calls, and remove the
"SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .
This will force people to configure SSL/TLS using "TLSServerParameters" and
"TLSClientParameters" elements in "security.xsd" for spring
configuration and
"setTLSServerParameters()" and "setTLSClientParameters()" calls for
programmatic
configuration..
The next thing in the proposal to take care of the same time, is that
there is an issue about
conflicts in SSL/TLS configuration, which is hard, if not impossible, to
mitigate. This issue is that
there is a setTLSServerParameters() on the AbstractHTTPDestination and
also on
the JettyHTTPServerEngine.
The problem is that the JettyHTTPServerEngine can get its TLS
configuration from 2 places.
One being Spring configuration on bean name based on its implementation
"org.apache.cxf.http_jetty.JettyHTTPServerEngine.<port#>"
and the other indirectly by the configuration of the HTTPDestination,
because the destination
also holds a TLSServerParameters property.
This has consequences. The JettyHTTPServerEngineFactory creates
JettyHTTPServerEngine which
basically holds a configured java.net.ServerSocket or SSLServerSocket
depending
on whether the TLS configuration is present. The factory also caches
these so that different
HTTPDestinations can be published on the same socket (port number).
This leads to problems in the such as:
Endpoint.publish("https://localhost:9000/foo", ...);
Endpoint.publish("https://localhost:9000/bar",...);
when the second publish tries to "reconfigure" the retrieved already
configured JettyHTTPServerEngine
due to the HTTPDestination trying to submit its TLSServerParameters to
the already configured
JettyHTTPServerEngine.
The next item in the proposal is to remove SSL/TLS configuration (both
Spring and programmatic)
from the HTTPDestination all together, and only be able to configure the
SSL/TLS through the
JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is
merely HTTP over a JSSE
configured Socket.
Several things would need to be done to get this to work well.
Remove the methods
set/getSslServer()
set/getTLSServerParameters
from the AbstractHTTPDesination
and add:
JettyHTTPServerEngine getJettyHttpServerEngine();
to JettyHTTPDestination so that programmatic configuration may happen
like so:
EndpointImpl endpoint;
TLSServerParameters parms;
((JettyHTTPDestination)endpoint.getServer().getDestination()).
getJettyHTTPServerEngine().setTLSServerParameters(parms);
So, in summary of this entire proposal is the following:
1. Remove TLS configuration from the AbstractHTTPDestination.
2. Create an API to retrieve the JettyHTTPServerEngine from the
JettyHTTPDestination
3. Remove setSslServer() and setSslClient() from the APIs and remove
SSLServerPolicy
and SSLClientPolicy from the security.xsd.
4. Create a QName sutiable for Spring configuring the
JettyHTTPServerEngine without
using the internal fully qualified class name of its implementation.
I'll be working on this patch this afternoon. So please come up with any
discussion,
complaints, or suggestions (like for the QName Bean name for the
JettyHTTPServerEngine
spring configuration) ASAP.
Thanks,
-Polar
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
Sergey Beryozkin wrote:
> Hi
>
>> Endpoint.publish("https://localhost:9000/foo", ...);
>> Endpoint.publish("https://localhost:9000/bar",...);
>>
>> when the second publish tries to "reconfigure" the retrieved already
>> configured JettyHTTPServerEngine
>> due to the HTTPDestination trying to submit its TLSServerParameters
>> to the already configured
>> JettyHTTPServerEngine.
>
> This is an internal detail. A client code calling
> Endpoint.publish("https://localhost:9000/bar") has no intention
> whatsover to reconfigure the port, its only intention is to register a
> provider serving a given context. That's it.
> With the older version one could just easily set programmatically the
> port ssl configuration (for port 9000) in this case. And then have the
> code registering providers, with no reconfiguration happening and
> without even knowing anything about ssl.
Correct, the desired model, is that the call doesn't have any intention
of reconfiguring the port, so therefore SSL/TLS configuration
information is not needed on the HTTPDestination. Enpoint.publish
creates an
HTTPDestination that may be spring configured or later programmatically
(re)configured. We eliminate the
conflict with the ServerEngine configuration by removing the SSL/TLS
configuration information from the
HTTPDestination and just leave it on the JettyHTTPServerEngine.
>
> 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 ?
No, because the port (read: JettyHTTPServerEngine) is configured with
the Keystore.
> What is the point of calling
> setTLSServerParameters(parms); per every endpoint sharing the same port ?
>
Right, that is why we get rid of it off the HTTPDestination.
> IMHO, from the application's perspective, it's much simplier to just
> configure a https bean representing the given port once, it's probably
> even more portable as it does not depend omn the fact the endpoint may
> have a server which may have a destination which may have an engine
>
We understand that, and that is what we are working for. Except for
right now the model violates that
principal.
> IMHO the internal code should only assume the reconfiguration attempt
> has happend if the request came through the explicit public api
Don't fret, I think the proposed solution gets you what you want.
Cheers,
-Polar
> Thanks, Sergey
>
>
>> Greetings,
>>
>> As you know there as been some work done to correct/enhance the use
>> of SSL/TLS
>> in the Http modules. CXF-661, CXF-666, CXF-672.
>>
>> In that effort, a significant change in the parameters for SSL/TLS
>> was required. It
>> added a new
>>
>> setTLSServerParameters(TLSServerParameters params)
>>
>> call in which the TLSServerParameters is more in-line with the JSSE,
>> which is
>> used exclusively for SSL/TLS transports. However, I kept the
>>
>> setSSLServer(SSLServerPolicy policy)
>>
>> call in order to maintain and not to break any existing
>> configurations both
>> Spring and programmatic. Analogous stuff was done for the client side.
>>
>> However, I have deprecated "setSSLServer()" and everything else
>> internally that is related
>> to it. That approach seems to be working. There seem to be some
>> complaints about the
>> "deprecation" compiler warnings.
>>
>> The question is for version 2.0, since we are moving from 1.x, do we
>> want to eliminate the
>> old configuration all together? My feeling and some consensus relayed
>> to me is "yes".
>>
>> I propose that we do remove the "setSslServer()" and "setSslClient()"
>> calls, and remove the
>> "SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .
>>
>> This will force people to configure SSL/TLS using
>> "TLSServerParameters" and
>> "TLSClientParameters" elements in "security.xsd" for spring
>> configuration and
>> "setTLSServerParameters()" and "setTLSClientParameters()" calls for
>> programmatic
>> configuration..
>>
>> The next thing in the proposal to take care of the same time, is that
>> there is an issue about
>> conflicts in SSL/TLS configuration, which is hard, if not impossible,
>> to mitigate. This issue is that
>> there is a setTLSServerParameters() on the AbstractHTTPDestination
>> and also on
>> the JettyHTTPServerEngine.
>>
>> The problem is that the JettyHTTPServerEngine can get its TLS
>> configuration from 2 places.
>> One being Spring configuration on bean name based on its implementation
>> "org.apache.cxf.http_jetty.JettyHTTPServerEngine.<port#>"
>> and the other indirectly by the configuration of the HTTPDestination,
>> because the destination
>> also holds a TLSServerParameters property.
>>
>> This has consequences. The JettyHTTPServerEngineFactory creates
>> JettyHTTPServerEngine which
>> basically holds a configured java.net.ServerSocket or SSLServerSocket
>> depending
>> on whether the TLS configuration is present. The factory also caches
>> these so that different
>> HTTPDestinations can be published on the same socket (port number).
>> This leads to problems in the such as:
>>
>> Endpoint.publish("https://localhost:9000/foo", ...);
>> Endpoint.publish("https://localhost:9000/bar",...);
>>
>> when the second publish tries to "reconfigure" the retrieved already
>> configured JettyHTTPServerEngine
>> due to the HTTPDestination trying to submit its TLSServerParameters
>> to the already configured
>> JettyHTTPServerEngine.
>>
>> The next item in the proposal is to remove SSL/TLS configuration
>> (both Spring and programmatic)
>> from the HTTPDestination all together, and only be able to configure
>> the SSL/TLS through the
>> JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is
>> merely HTTP over a JSSE
>> configured Socket.
>>
>> Several things would need to be done to get this to work well.
>> Remove the methods
>> set/getSslServer()
>> set/getTLSServerParameters
>> from the AbstractHTTPDesination
>> and add:
>> JettyHTTPServerEngine getJettyHttpServerEngine();
>> to JettyHTTPDestination so that programmatic configuration may happen
>> like so:
>>
>>
>> EndpointImpl endpoint;
>> TLSServerParameters parms;
>>
>> ((JettyHTTPDestination)endpoint.getServer().getDestination()).
>>
>> getJettyHTTPServerEngine().setTLSServerParameters(parms);
>>
>>
>>
>> So, in summary of this entire proposal is the following:
>>
>> 1. Remove TLS configuration from the AbstractHTTPDestination.
>> 2. Create an API to retrieve the JettyHTTPServerEngine from the
>> JettyHTTPDestination
>> 3. Remove setSslServer() and setSslClient() from the APIs and remove
>> SSLServerPolicy
>> and SSLClientPolicy from the security.xsd.
>> 4. Create a QName sutiable for Spring configuring the
>> JettyHTTPServerEngine without
>> using the internal fully qualified class name of its implementation.
>>
>> I'll be working on this patch this afternoon. So please come up with
>> any discussion,
>> complaints, or suggestions (like for the QName Bean name for the
>> JettyHTTPServerEngine
>> spring configuration) ASAP.
>>
>> Thanks,
>> -Polar
>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
Sergey Beryozkin wrote:
> 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 :-)
>
>
Thanks Sergey, I do that all the time, on all my instruments except the
fiddle (no frets). :-)
cheers,
-Polar
>
>> 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
>>>>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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
>>>>>>
>>>>>>
>>>>>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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
>>>>>
>>>>>
>>>>>
>>>>>
Re: Http/s configuration Proposal
Posted by Sergey Beryozkin <se...@iona.com>.
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
>>>>
>>>>
>>>>
>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
The same would have to be done with the listener policy.
<jettyServerEngineFactory bus="cxf">
<defaultListenerParameters>
<MinThreads>12</MinThreads>
<MaxThreads>200</MaxThreads>
</defaultListenerParameters>
<defaultTlsParameters>
....
</defaultTlsParameters>
<listener port="1234">
<tlsParameters>
....
</tlsParameters>
</listener>
</jettyServerEngineFactory>
The only thing please correct me if I am wrong, but it appears that the
http-conf:HTTPListenerPolicy
is not used.
Eclipse can't find anything that calls getListener() or reference its
local "listener" significantly.
Should we get rid of the http-conf:HTTPListenerPolicy? and
http-listener.xsd entirely?
Cheers,
-Polar
Polar Humenn wrote:
> 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
>>>>
>>>>
>>>>
>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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
>>>
>>>
>>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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
>>
>>
>>
RE: Http/s configuration Proposal
Posted by "Glynn, Eoghan" <eo...@iona.com>.
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
>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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(JettyHTTPServerEngineFactory.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
Re: Http/s configuration Proposal
Posted by Sergey Beryozkin <se...@iona.com>.
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
>>
>
Re: Http/s configuration Proposal
Posted by Polar Humenn <ph...@iona.com>.
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
>
Re: Http/s configuration Proposal
Posted by Sergey Beryozkin <se...@iona.com>.
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
Re: Http/s configuration Proposal
Posted by Fred Dushin <fr...@dushin.net>.
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
Re: Http/s configuration Proposal
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
> Endpoint.publish("https://localhost:9000/foo", ...);
> Endpoint.publish("https://localhost:9000/bar",...);
>
> when the second publish tries to "reconfigure" the retrieved already configured JettyHTTPServerEngine
> due to the HTTPDestination trying to submit its TLSServerParameters to the already configured
> JettyHTTPServerEngine.
This is an internal detail. A client code calling Endpoint.publish("https://localhost:9000/bar") has no intention whatsover to
reconfigure the port, its only intention is to register a provider serving a given context. That's it.
With the older version one could just easily set programmatically the port ssl configuration (for port 9000) in this case. And then
have the code registering providers, with no reconfiguration happening and without even knowing anything about ssl.
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 ?
IMHO, from the application's perspective, it's much simplier to just configure a https bean representing the given port once, it's
probably even more portable as it does not depend omn the fact the endpoint may have a server which may have a destination which may
have an engine
IMHO the internal code should only assume the reconfiguration attempt has happend if the request came through the explicit public
api
Thanks, Sergey
> Greetings,
>
> As you know there as been some work done to correct/enhance the use of SSL/TLS
> in the Http modules. CXF-661, CXF-666, CXF-672.
>
> In that effort, a significant change in the parameters for SSL/TLS was required. It
> added a new
>
> setTLSServerParameters(TLSServerParameters params)
>
> call in which the TLSServerParameters is more in-line with the JSSE, which is
> used exclusively for SSL/TLS transports. However, I kept the
>
> setSSLServer(SSLServerPolicy policy)
>
> call in order to maintain and not to break any existing configurations both
> Spring and programmatic. Analogous stuff was done for the client side.
>
> However, I have deprecated "setSSLServer()" and everything else internally that is related
> to it. That approach seems to be working. There seem to be some complaints about the
> "deprecation" compiler warnings.
>
> The question is for version 2.0, since we are moving from 1.x, do we want to eliminate the
> old configuration all together? My feeling and some consensus relayed to me is "yes".
>
> I propose that we do remove the "setSslServer()" and "setSslClient()" calls, and remove the
> "SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .
>
> This will force people to configure SSL/TLS using "TLSServerParameters" and
> "TLSClientParameters" elements in "security.xsd" for spring configuration and
> "setTLSServerParameters()" and "setTLSClientParameters()" calls for programmatic
> configuration..
>
> The next thing in the proposal to take care of the same time, is that there is an issue about
> conflicts in SSL/TLS configuration, which is hard, if not impossible, to mitigate. This issue is that
> there is a setTLSServerParameters() on the AbstractHTTPDestination and also on
> the JettyHTTPServerEngine.
>
> The problem is that the JettyHTTPServerEngine can get its TLS configuration from 2 places.
> One being Spring configuration on bean name based on its implementation
> "org.apache.cxf.http_jetty.JettyHTTPServerEngine.<port#>"
> and the other indirectly by the configuration of the HTTPDestination, because the destination
> also holds a TLSServerParameters property.
>
> This has consequences. The JettyHTTPServerEngineFactory creates JettyHTTPServerEngine which
> basically holds a configured java.net.ServerSocket or SSLServerSocket depending
> on whether the TLS configuration is present. The factory also caches these so that different
> HTTPDestinations can be published on the same socket (port number).
> This leads to problems in the such as:
>
> Endpoint.publish("https://localhost:9000/foo", ...);
> Endpoint.publish("https://localhost:9000/bar",...);
>
> when the second publish tries to "reconfigure" the retrieved already configured JettyHTTPServerEngine
> due to the HTTPDestination trying to submit its TLSServerParameters to the already configured
> JettyHTTPServerEngine.
>
> The next item in the proposal is to remove SSL/TLS configuration (both Spring and programmatic)
> from the HTTPDestination all together, and only be able to configure the SSL/TLS through the
> JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is merely HTTP over a JSSE
> configured Socket.
>
> Several things would need to be done to get this to work well.
> Remove the methods
> set/getSslServer()
> set/getTLSServerParameters
> from the AbstractHTTPDesination
> and add:
> JettyHTTPServerEngine getJettyHttpServerEngine();
> to JettyHTTPDestination so that programmatic configuration may happen like so:
>
>
> EndpointImpl endpoint;
> TLSServerParameters parms;
>
> ((JettyHTTPDestination)endpoint.getServer().getDestination()).
> getJettyHTTPServerEngine().setTLSServerParameters(parms);
>
>
>
> So, in summary of this entire proposal is the following:
>
> 1. Remove TLS configuration from the AbstractHTTPDestination.
> 2. Create an API to retrieve the JettyHTTPServerEngine from the JettyHTTPDestination
> 3. Remove setSslServer() and setSslClient() from the APIs and remove SSLServerPolicy
> and SSLClientPolicy from the security.xsd.
> 4. Create a QName sutiable for Spring configuring the JettyHTTPServerEngine without
> using the internal fully qualified class name of its implementation.
>
> I'll be working on this patch this afternoon. So please come up with any discussion,
> complaints, or suggestions (like for the QName Bean name for the JettyHTTPServerEngine
> spring configuration) ASAP.
>
> Thanks,
> -Polar
>