cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: [proposal] ConfigurationProvider/Bean configuration
Date Wed, 06 Dec 2006 12:30:16 GMT
Dan Diephouse wrote:

> Hi All,
>
> I've been looking through the configuration code and I wanted to make 
> a few
> suggestions for cleaning things up. It seems we've simplified things a 
> bit,
> but I think they can be simpler and cleaner yet. (BTW, I'm 
> volunteering to
> make these changes)
>
> [Bean Configuration]
> Currently all the generated beans extend AbstractConfigurableBeanBase. 
> ACBB
> has a list of "overwriteProviders" and "fallkbackProviders."  These are
> lists of ConfigurationProviders. When a bean's getter is called, an
> overwrite provider is queried first to see if it has a value. If it 
> doesn't,
> the bean's field is queried. If it doesn't have a value, the
> fallbackproviders are tried. Currently ConfigurationProviders are only 
> used
> in the HTTP and JMS code to provide data for a couple values.
>
> Lets take a peek at what happens when we want to find the 
> HTTPServerPolicy
> for a JettyHTTPDestination:
> 1. HTTPDestinationConfigBean.getServer() is called. JettyHTTPDestination
> indirectly extends HTTPDestinationConfigBean.
> 2. The overwrite providers are tried.
> 3. The HTTP module has a provider called ServiceModelHttpProvider 
> which is
> in the provider list. ServiceModelHttpProvider.getObject("server") is
> called.
> 4. Inside SMHP there is conditional code for each property - if
> ("server".equals(name))... else if ("client".equals(name))... etc. Since
> we're looking for the server property that conditioinal is triggered
> 5. SMHP returns the value from EndpointInfo.getExtensor(
> HTTPServerPolicy.class);
> 6. If the result from #5 was null, the field from 
> HTTPDestinationConfigBean
> is checked to see if it has a value. If it does (and it does), it returns
> 7. If there were no value, the fallback providers would have been 
> checked.
>
> This is an OK process, but I think it is unnecessarily complex for 
> what we
> need to do. Why?
>
>   - Currently there no fallback providers and there are only two
>   ConfigurationProviders. I don't see any obvious need for them 
> either. Am I
>   missing something?
>   - The two configuration providers are for the JMS and HTTP modules.
>   They are both responsible for querying the service model. This seems 
> to hint
>   that maybe there is a pattern here which we should be aware of... (more
>   below)
>   - The configuration providers need to be explicitly aware of the
>   properties being queried and the values expected for that property.
>
> I think the above boils down to this:
> 1. Check to see if there is a configuration bean in the service model
> 2. If so return that bean.
> 3. If not return a default configuration bean.

Hi Dan,

The idea is to be able to supersede the information in the service model 
with a non-default configuration bean, and only if the latter is not 
available,  use a default bean. I.e. consider two very different sources 
(service model on the one hand and bean provider/container on the other) 
for non-default values.
I would consider the service model as something rather static, and beans 
as more dynamic.
One could argue that a contract is a contract, and should not be 
changed, but in practice it seems a useful thing to do at least in a 
development environment:  it's easier to change a bean configuration 
file locally than a wsdl in a possibly remote location.

BTW aside from transport policies, WS-policies such as the RMAssertion 
are candidates where we may want to supersede the settings with beans 
supplied by the container (the provider to obtain the assertion from the 
service model is just not implemented/installed yet).

I agree that the approach is complex, but considering that the 
complexity is hidden to the consumer, I'd be wary to remove it. Beans 
for which property values will never be found anywhere except in the 
bean definition need not be generated using the xjc plugins.

Andrea.

>
> My proposal is simply this: Lets just do the above 3 steps wherever we 
> need
> to find the appropriate configuration bean. Or in code form:
>
> HttpServerPolicy getServer() {
>  HttpServerPolicy policy = 
> endpointInfo.getExtensor(HttpServerPolicy.class
> );
>  if (policy == null) policy = getDefaultPolicy();
>  return policy;
> }
>
> Or we could add a utility method to traverse the service model and 
> check the
> binding/service as well. I think there are several advantages: simpler 
> code,
> less code, and no need for highly customized jaxb beans. I don't see any
> downsides - is there something I'm missing here?
>
> Regards,
> - Dan



Mime
View raw message