It appears that the get/setAuthorization for an HTTPDestination does
nothing.
And this is confusing at best. What is this supposed to be? Is it
supposed to be
a username and password a client is supposed to match?
In anycase, that kind of method can be superceeded by an interceptor
that can
throw back a 401 to the client.
I'm going to remove it from the Destination configuration, and remove
the http-listener.xsd, HTTPListenerPolicy from http-conf.xsd, and remove
HTTPListenerConfigBean class, as ServerEngines will now be configured by
the factory configuration.
Cheers,
-Polar
Polar Humenn wrote:
Ah, I thought the custom configurer was your desired approach.
But I suppose if all you created the Custom Configurer for was to
configure the JettyHTTPServerEngine, then I guess not!
Cheers,
-Polar
Sergey Beryozkin wrote:
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
