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