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: Configuration
Date Thu, 25 Jan 2007 12:09:25 GMT
Dan Diephouse wrote:

> Hi Andrea,
>
> On 1/24/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
>>
>> To sum up,  my main concerns are:
>>
>> * Use of static APIs (I don't see how this can get around keeping
>> references to the bus all over the place as the bus itself is not 
>> static).
>
>
>
> I meant something like this:
>
> public static  <T> T getConfiguration(AbstractPropertiesHolder props, T
> defaultValue, Class<T> type);
>
> The point of the getConfiguration method isn't to introduce a 
> Configuration
> type interface, its merely to encapsulate the logic which traverses the
> service model. For example:
>
>    public <T> T getConfiguration(AbstractPropertiesHolder props, T
> defaultValue, Class<T> type) {
>        T value = props.getExtensor(type);
>
>        if (value == null) {
>            if (props instanceof EndpointInfo) {
>                value = getServiceModelValue((EndpointInfo) props, type);
>            }
>
>            if (value == null) {
>                value = defaultValue;
>            }
>        }
>
>        return value;
>    }
>
>    private <T> T getServiceModelValue(EndpointInfo info, Class<T> type) {
>        T value = null;
>
>        BindingInfo b = info.getBinding();
>        if (value == null && b != null) {
>            value = b.getExtensor(type);
>        }
>
>        ServiceInfo s = info.getService();
>        if (s != null && value == null) {
>            value = s.getExtensor(type);
>        }
>
>        return value;
>    }
>
> Ideally there would be support for getting properties from Messages and
> Operations as well though.

My impression was that bus.getConfiguration(...), or something else,  
was supposed to do all of what you listed earlier:
 >The resolution order would be like this:
 >1. The default value - i.e. new HTTPServerPolicy();
 >2. The value found on the service model - this would potentially be 
from the WSDL.
 >3. The value set on the bean in the config file
 >4. The value set on the bean via "other stuff" aka 
BeanFactoryPostProcessors/BeanPostProcessors

But I realise it's really only seaching the service model  (and as such 
there is no need for it to be static), and that there will be no 
mechanism in place to ensure that steps 1. to 3. are done consistently 
every time a property is needed (4. is not an issue as it happens in the 
background).

>
> * Reintroduction of configuration APIs - although IMO this would not be
>
>> so bad,  Celtix has lived with cfg APIs long enough. I just find the
>> idea surprising after the discussions that took place on this mailing
>> list half a year earlier.
>
>
>
> I view this as quite different from the Configuration APIs. The
> Configuration APIs were basically a hierarchical tree of values.
> getConfiguration().getChild(...).getValue(). 

No - the hierarchy was gone by the time code was dropped into the apache 
repository. It was instead like:
getConfiguration().getValue(...)

> The proposed solution is just a
> convenience method for finding values in the service model. This 
> allows the
> containers to do their thing (xml/db/properties config, wiring) and still
> allows us to get values from the service model.
>
> The method really might be better named "getServiceModelExtensor" 
> instead of
> getConfigurationValue...
>
> * If configuration APIs are reintroduced I would like to see them used
>
>> consistently. If bean clients end up doing this:
>> T t = bean.getTValue();
>> in some places and:
>> T t = bus.getConfiguration(endpointInfo, defaultT, T.class);
>> or:
>> T t = bus.getConfiguration(endpointInfo, bean.getTValue(), T.class);
>> in others places I'd consider that a source of
>> problems/inconsistencies.  But maybe others don't think it's as big
>> problem as I think it is?
>
>
>
> I think the same consistencies arise with the  current approach. I can
> easily forget or not realize that I have to have a ConfigurationProvider
> check for a value in the service model. Both approaches require some 
> manual
> wiring.

No - this is one of the main  advantages of the current/previous 
approaches: clients only ever make *one call* to the bean's getter/to 
the component'ss configuration object. The traversal of the service 
model,  and the precedence between default, injected and service model 
value need were never of concern to the client.
Do you not think that instead of repeat coding steps 1. to 3.  above,  
people end up writing wrappers that do just that (effectively making up 
for what was previously hidden in the the 'extended getters'/the 
configuration API)? I would.

Andrea.

> - Dan
>
>
>


Mime
View raw message