Dan Diephouse wrote:
One change I made locally is to have
ServiecModelHttpConfiguration.getObject(name) return
endpointInfo.getProperty(name) on line 50 as opposed to returning null.
Hi Dan,
IMO that's fine - the only reason that
ServiceModelHttpConfigurationProvider returned null for all but the
"server" and "client" properties is that up to now we only expected to
find values for these two properties in the service model - if they
are supplied as wsdl extensors.
If values for these or other properties can also be expected in the
EndpointInfo's (or ServiceInfo's) property map, these maps should be
consulted also - either by the same provider or a different one.
The reason that only Endpoint info is searched is that the http policy
extensors are only registered for the port element (I believe so at
least, can't find the registering code at the moment). But I don't see
any reasons for not registering the policies as extensors of the binding
or portType elements also (and have the provider look there too).
Andrea.
This allows me to do this:
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setServiceClass(CustomerService.class);
sf.setBindingFactory(new HttpBindingInfoFactoryBean());
sf.setAddress("http://localhost:9001/";);
Map<String, Object> props = new HashMap<String, Object>();
props.put("contextMatchStrategy", "stem");
sf.setProperties(props);
ServerImpl svr = (ServerImpl) sf.create();
If someone can shed some light as to whether this was a good/bad thing
to do I'd appreciate it :-)
- Dan
Dan Diephouse wrote:
Hiya (CC'ing people directly as the dev list still isn't working)
I was wondering if you could explain the HTTP configuration to me a
bit. I am looking at changing the "contextMatchStrategy" setting and
wondering:
1. How would I change it globally?
2. How would I change it at the service/endpoint level?
Right now I'm doing this:
((JettyHTTPDestination)
server.getDestination()).setContextMatchStrategy("stem");
It works, but its not very Spring amenable. I'm wondering what a
better way is :-)
There seems to be a ServiceModelHttpConfigurationProvider class that
looks at the EndpointInfo, but I'm wondering why do we need to
support multiple configuration providers. Couldn't we just assume
that if there is going to be something overriding the configuration
it will be in the service model? WSDL extensors should end up there,
as could user configured values. Additionally, I think it would be
good to check things beside the EndpointInfo, like the Service itself.
Thanks,
- Dan
