cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Configuration
Date Wed, 24 Jan 2007 19:37:00 GMT


On Wednesday 24 January 2007 14:23, Dan Diephouse wrote:
> 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:

Out of curiosity, could this just moved into the model directly?   Basically, 
add a method to AbstractPropertiesHolder like:
public <T> T traverseAndGetExtensor(T defaultValue, Class<T> type) {
        T t = getExtensor
        if (t == null) {
             t = defaultValue;
        }
	return t;
}

and then override it in  EndpointInfo and any of the other servicemodel 
components that may need to do so.

Would that work?
Dan


>
>     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

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com

Mime
View raw message