Re: [Springframework-developer] new bean factory and application context features

[Colin S. <col...@ex...>]

jürgen höller [werk3AT] wrote:

>Fortunately, this *is* available for XmlBeanFactory too, like as follows -- 
>with the very same API that XmlWebApplicationContext internally uses to load multiple files.
> 
>  XmlBeanFactory bf = new XmlBeanFactory();
>  bf.loadBeanDefinitions("appCtx1.xml");
>  bf.loadBeanDefinitions("appCtx1.xml");
>  bf.preInstantiateSingletons();
> 
>It's currently not available in FileSystemXmlApplicationContext though, mainly to not place any restrictions on file names in terms of spaces or commas. FileSystemXmlApplicationContext already has a constructor with a String array, for automatically setting up *nested* contexts. We could redefine that constructor to specify multiple files that make up a *single* context, and offer an overloaded version that takes a parent ApplicationContext reference. That way, both multiple files for a single context and nesting would be possible.
> 
>  
>
That sounds good. There are certain deployment scenarios where config 
files references via filenames (as opposed to having to be on the 
classpath) are a lot more convenient, and I think. I am trying to think 
if there are any use cases where somebody would be feeding in a list of 
contexts in the existing implementation, and would be worst off if they 
were nested as opposed to flattened into one as you propose. I can't 
really think of any. I think the nesting does make a lot of sense when 
you are assembling together contexts from different layers which may 
already exist (that is, the lower layer(s) may already exist), as per my 
multi-webapp usecase, but in this case you are doing it dynamically 
anyways, and can't do it as a list.

>-----
> 
>What I'm most excited about is the BeanPostProcessor hook. I expect that to be very powerful, as already indicated by the respective test case in StaticApplicationContextSuite. Another example that I've prototyped is the following (not yet in CVS):
>public class AutoProxyCreator implements BeanPostProcessor {
>  private List beanNames;
>  private Interceptor[] interceptors;
>
>  public void setBeanNames(String[] beanNames) {
>    this.beanNames = Arrays.asList(beanNames);
>  }
>
>  public void setInterceptors(Interceptor[] interceptors) {
>    this.interceptors = interceptors;
>  }
>
>  public Object postProcessBean(Object bean, String name, RootBeanDefinition definition) {
>    if (this.beanNames != null && this.beanNames.contains(name)) {
>      ProxyFactory proxyFactory = new ProxyFactory();
>      for (int i = 0; i < this.interceptors.length; i++) {
>        proxyFactory.addInterceptor(this.interceptors[i]);
>      }
>      proxyFactory.addInterceptor(new InvokerInterceptor(bean));
>      return proxyFactory.getProxy();
>    }
>    else {
>      return bean;
>    }
>  }
>}
>
>This is a BeanPostProcessor bean that can be set up as follows to proxy the beans with the given names with the given interceptors. Note that this is only one bean with proxy settings to define, although there might be dozens of target beans with the same proxy behavior.
>
><bean id="autoProxyCreator" class="org.springframework.aop.framework.support.AutoProxyCreator">
>  <property name="beanNames"><value>myBean1,myBean2,myBean3</value></property>
>  <property name="interceptors>
>    <list>
>      <ref bean="myInterceptor1"/>
>      <ref bean="myInterceptor2"/>
>    </list>
>  </property>
></bean>
>
>So setting up 10 transactional beans would just involve 1 AutoProxyCreator and 1 transaction interceptor plus the 10 target beans (12 beans in total), instead of 10 TransactionProxyFactoryBeans plus the 10 target beans (20 beans in total). The transaction attributes would be centralized though, in contrast to TransactionProxyFactoryBean that keeps them local per individual proxy definition.
>  
>
I really like this. It will reduce boilerplate proxy definitions for 80% 
of the code that needs simple wrapping of everything...