Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950701221056m13dcfc8bofdb5640311d0416c@mail.gmail.com>
Date: Mon, 22 Jan 2007 13:56:23 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Configuration
In-Reply-To: <45B4D7BF.9050707@iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_173856_21593863.1169492183190"
References: <7b774c950701181428g19c5af20gfaad699fda67139d@mail.gmail.com>
	 <45B4D7BF.9050707@iona.com>

------=_Part_173856_21593863.1169492183190
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

OK, first let me try to give a little more context, and then I'll try to
answer your specific questions.

In our current code we have a ConfigurationProvider mechanism. As I
understand the motivation for this as it allows configuration values to come
form places other than the bean itself. Supporting this use case is a Good
Thing.

As I dug through Spring 2's documentation, I noticed the
BeanFactoryPostProcessor interface [1]. This allows customizing of how the
beans are configured. One example of this bean is the
PropertyOverrideConfigurer
bean. It can take values from a properties file and override a bean's
properties with them. Other examples take configuration from web.xml files
or from databases. Spring can take a list of these BeanFactoryPostProcessors
and they can be ordered. This means our configuration can come from anywhere
with the one notable exception of the service model.

I'm thinking, this seems to do exactly what we want and it doesn't req


1.
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/BeanFactoryPostProcessor.html

On 1/22/07, Andrea Smyth <andrea.smyth@iona.com> wrote:
>
> Dan Diephouse wrote:
>
> > Hi All,
> >
> > Just wanted to propose something a bit more concrete via Configuration
> > before going about it. Basically we have these cases:
> > 1. Configuration comes from Spring XML
> > 2. Configuration comes from service model (WSDL, API)
> > 3. Configuration may come from some data source (Database, properties
> > file)
> >
> > Instead of the ConfigurationProvider approach we can simplify by
> > 1. Making beans just beans without our code generation customization
> > 2. Creating a method on the Bus to get configuration values:
> >
> > HTTPServerPolicy p = bus.getConfigurationValue(endpointInfo,
> > getDefaultHTTPServerPolicy(), HTTTPServerPolicy.class);
>
>
> Do you want to reintroduce configuration APIs -  what about testability?
> It looks like every bean client will need access to the bus ...
>
> Also not sure how this API is to be used, specifically
> a) when should a bean client use the bean's getter only/when should it
> use the bean's getter and/or the above API?


Any time

b) where does the default value come from? In order to distinguish
> default value from in injected value (i.e. value coming from sources 1.
> and 3. above) and value coming from service model it looks like every
> bean should have a
> T getTProperty();
> and a
> // no (public) setter for this one
> T getDefaultTProperty(); ?
> Where is the preference of injected value vs. default value vs. obtained
> from service model determined? IMO it's important this happens in one
> place only, and if it's in bus.getConfigurationValue(...) we need to
> pass both the default and the injected value.
>
> >
> > The method definition would be something like this:
> >
> > <T> T getConfigurationValue(AbstractPropertiesHolder, T defaultValue,
> > Class<T> type);
> >
> > This method would then search through the Bus, Endpoint, etc for the
> > HTTPServerPolicy value. If none is found the default value is returned.
>
> What do you mean with searching through the Bus?
>
> >
> > You may ask, isn't it simpler to just call getHTTPServerPolicy() on the
> > current code? In actuality no, because we need to write
> > ConfigurationProviders which actually search the service model, so its
> > more
> > code.
>
> One generic ConfigurationProvider can be used in most if not all cases,
> and there would be no more code to that than there would be to the
> implementation of the above getConfigurationValue - in fact they'd be
> pretty much the same thing.
>
The point


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

------=_Part_173856_21593863.1169492183190--