The same would have to be done with the listener policy.
<jettyServerEngineFactory bus="cxf">
<defaultListenerParameters>
<MinThreads>12</MinThreads>
<MaxThreads>200</MaxThreads>
</defaultListenerParameters>
<defaultTlsParameters>
....
</defaultTlsParameters>
<listener port="1234">
<tlsParameters>
....
</tlsParameters>
</listener>
</jettyServerEngineFactory>
The only thing please correct me if I am wrong, but it appears that the
http-conf:HTTPListenerPolicy
is not used.
Eclipse can't find anything that calls getListener() or reference its
local "listener" significantly.
Should we get rid of the http-conf:HTTPListenerPolicy? and
http-listener.xsd entirely?
Cheers,
-Polar
Polar Humenn wrote:
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
