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 <[EMAIL PROTECTED]> 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
