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 20:09:16 GMT
I think I'd be ok with this. I don't see any downside at the moment.
- Dan

On 1/24/07, Daniel Kulp <daniel.kulp@iona.com> wrote:
>
>
>
> 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
>



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

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