cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: Configuration
Date Mon, 22 Jan 2007 15:26:55 GMT
Dan Diephouse wrote:

> Hi All,
> Just wanted to propose something a bit more concrete via Configuration
> before going about it. Basically we have these cases:
> 1. Configuration comes from Spring XML
> 2. Configuration comes from service model (WSDL, API)
> 3. Configuration may come from some data source (Database, properties 
> file)
> Instead of the ConfigurationProvider approach we can simplify by
> 1. Making beans just beans without our code generation customization
> 2. Creating a method on the Bus to get configuration values:
> HTTPServerPolicy p = bus.getConfigurationValue(endpointInfo,
> getDefaultHTTPServerPolicy(), HTTTPServerPolicy.class);

Do you want to reintroduce configuration APIs -  what about testability?
It looks like every bean client will need access to the bus ...

Also not sure how this API is to be used, specifically
a) when should a bean client use the bean's getter only/when should it 
use the bean's getter and/or the above API?
b) where does the default value come from? In order to distinguish 
default value from in injected value (i.e. value coming from sources 1. 
and 3. above) and value coming from service model it looks like every 
bean should have a
T getTProperty();
and a
// no (public) setter for this one
T getDefaultTProperty(); ?
Where is the preference of injected value vs. default value vs. obtained 
from service model determined? IMO it's important this happens in one 
place only, and if it's in bus.getConfigurationValue(...) we need to 
pass both the default and the injected value.

> The method definition would be something like this:
> <T> T getConfigurationValue(AbstractPropertiesHolder, T defaultValue,
> Class<T> type);
> This method would then search through the Bus, Endpoint, etc for the
> HTTPServerPolicy value. If none is found the default value is returned.

What do you mean with searching through the Bus?

> You may ask, isn't it simpler to just call getHTTPServerPolicy() on the
> current code? In actuality no, because we need to write
> ConfigurationProviders which actually search the service model, so its 
> more
> code.

One generic ConfigurationProvider can be used in most if not all cases, 
and there would be no more code to that than there would be to the 
implementation of the above getConfigurationValue - in fact they'd be 
pretty much the same thing.


> Additionally it requires code customization for the beans which is a
> pain. This would be easier for people writing extensions to CXF to use.
> The getConfigurationValue() method would delegate to a 
> ConfigurationManager
> interface which would contain this method and allow people to plug in
> different ways of doing resolution. For instance, by having the bus 
> always
> override values.
> Spring can actually take configuration from the database and properties
> files, so I think this covers all our bases. 

> And if the container can't
> cover some edge case I think people can pretty easily override the 
> default
> ConfigurationManager with their own.
> (BTW, I'm not too keen on the getConfigurationValue name, so if you have
> suggestions let me know)
> Thoughts?
> Cheers,
> - Dan

View raw message