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
