Hi Sergey,
Glad you brought this code up. I think this is what it should be:
private static final String HTTP_LISTENER_NAME = "..."; <proposal still
sought>
private String listenerBeanName;
// The tlsParams will be null if not used.
private TLSServerParameters tlsParams =
initTLSServerParameters();
.....
public void configureBean(Object beanInstance) {
String beanName = getBeanName(beanInstance);
if (listenerBeanName.equals(beanName)
&& tlsParams != null)
{
// Is there a spring configuration?
super.configureBean(beanInstance);
// Make decision to override.
if (isSetTLSParameters()) {
LOG.fine("Overriding spring configuration of
TLSParameters for " + listenerBeanName);
// maybe throw configuration exception?
}
// Override
HTTPListenerConfigBean bean =
(HTTPListenerConfigBean)beanInstance;
bean.setTLSParameters(tlsParams);
}
}
The big difference here, is that you call super.configureBean() first
instead of last. Calling it
first makes you figure out if the application deployer actually
configured it using Spring and
XML. Your configurer can choose to ignore that if you wish, because it's
your code.
Having the the super.configureBean() in order to get what you wanted
forced the code in
CXF to ignore any call to setSslServer(). I believe that is wrong. CXF
should do what you
tell it to, and you should be notified if it isn't going to work.
The above setTLSParameters will work, regardless of whether the
TLSParameters are set or not
because the configuration will not be "finalized" on the bean in
question until after
Configurer. configureBean() is done.
Ok, given the above explanation, what is going to change for users
wishing to publish two providers serving different contexts on the
same 9090 port and configure the ssl setting of the port
programmatically? Sorry I don't understand you saying no need to
write this expression per each endpoint.publish, only if once needs to
do it programmatically
Nothing, unless people where doing trying to set two different keystores
on two different destinations that
were on the same Port. Actually what was happening in that case, is that
only the first configuration was
applicable. So, if Destination 1 wanted to publish on port 9000 and
wanted to authenticate as "Alice" and
Destination 2 wanted to publish on port 9000 and wanted to authenticate
as "Bob", Destination 2 was out
of luck in that case, and actually authentiicated as "Alice" without so
much as a warning.
Cheers,
-Polar
Thanks, Sergey
On May 30, 2007, at 11:58 AM, Sergey Beryozkin wrote:
With your proposal one needs to write this complex expression in
addition per every endpoint registration :
((JettyHTTPDestination)endpoint.getServer().getDestination()).
getJettyHTTPServerEngine
().setTLSServerParameters(parms);
Does it mean that for https://localhost:9000/bar one can point to
one keystore for ex and for
https://localhost:9000/foo one can point to another keystore ? What
is the point of calling
setTLSServerParameters(parms); per every endpoint sharing the same
port ?
No, one does not need to write this expression for each
endpoint.publish. You only need to do this if you want to configure
the server engine programatically. I think the point is, you should
be doing that on the server engine instance directly, not indirectly
through the Destination.
Just to allay any fears, this is being done precisely to support the
use case:
Endpoint.publish("https://www.acme.com:9090/foo";, ...);
Endpoint.publish("https://www.acme.com:9090/bar";, ...);
which is currently broken in CXF.
I think we're in agreement here.
-Fred
