cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Configuration
Date Wed, 24 Jan 2007 19:23:48 GMT
Hi Andrea,

On 1/24/07, Andrea Smyth <> 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

* 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

- Dan

Dan Diephouse
Envoi Solutions |

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