cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject [proposal] ConfigurationProvider/Bean configuration
Date Mon, 04 Dec 2006 20:30:56 GMT
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
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(
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
   - 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.

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?

- Dan
Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message