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:51:42 GMT


Thinking about this some more......

Isn't this backwords anyway?    
https://issues.apache.org/jira/browse/CXF-390

Shouldn't the spring fed value override the wsdl value?   Or at least merge 
in?     Use the values specified from spring to merge into the service model? 
(so the resulting wsdl generated from the service model has the "active" 
information?)

Dan



On Wednesday 24 January 2007 14:37, Daniel Kulp 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

Mime
View raw message