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
