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: <7b774c950701221057m6fa936f1k31c73ec682cd12cf@mail.gmail.com>
Date: Mon, 22 Jan 2007 13:57:22 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Configuration
In-Reply-To: <7b774c950701221056m13dcfc8bofdb5640311d0416c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_173888_4139032.1169492242498"
References: <7b774c950701181428g19c5af20gfaad699fda67139d@mail.gmail.com>
	 <45B4D7BF.9050707@iona.com>
	 <7b774c950701221056m13dcfc8bofdb5640311d0416c@mail.gmail.com>

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

Crap. I hit tab-enter accidentally while composing. :-( Will send off a
finished version soon....

On 1/22/07, Dan Diephouse <dan@envoisolutions.com> wrote:
>
> 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
>


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

------=_Part_173888_4139032.1169492242498--