cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Configuration
Date Wed, 24 Jan 2007 19:23:48 GMT
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.

* 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(). 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.

- Dan



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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