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:[EMAIL PROTECTED] Sent: 31 May 2007 14:38
To: [email protected]
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
