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 > >
