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:08:33 GMT
Is the CXF-390 backwards? Or is the proposed implementation backwards?

I agree with the comments in 390 and the way I proposed does support it.
First, you find/construct your default value. Then you do
setFoo(getConfigurationValue(serviceModel, defaultValue)) in the contructor.
That will set the "foo" property on the bean when it is constructed. Then
spring will come in and set its properties on the bean via <property
name="foo".../> or via post processors.

There does seem to be a possibility that the person could set the
configuration property to the service model value after the bean is built
though.

- Dan

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



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

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