[Springframework-developer] Bean factory refactoring

[<jue...@we...>]

Hi everybody,

In the past few days, I've refactored our bean factory implementations, =
mainly to reduce the size of AbstractAutowireCapableBeanFactory.

I've moved the current bean destruction logic up to AbstractBeanFactory, =
which is possible since 1.1 where dependent beans are determined =
differently. AbstractAutowireCapableBeanFactory is now just responsible =
for actual bean creation, with and without autowiring etc. I've also =
moved some supporting logic to a new AutowireUtils helper class.

In the course of this, I've noticed that the type check for prototype =
beans was incomplete: ProxyFactoryBean and =
AbstractPrototypeBasedTargetSource used =
ConfigurableListableBeanFactory.getBeanDefinition(name).getBeanClass(), =
which only regards the bean class of a specific bean definition. It did =
not cover a couple of other configuration options:

* a child bean definition that inherits the bean class from the parent
* a FactoryBean (explicit check in ProxyFactoryBean, none in APBTS)
* manually registered singletons (via registerSingleton)

Therefore, I've added a "Class getType(name)" method to the BeanFactory =
interface, trying to determine the type of the object returned by =
getBean upfront. AbstractBeanFactory's default implementaton properly =
merges bean definitions and handles FactoryBeans and manually registered =
singletons.

ProxyFactoryBean and AbstractPrototypeBasedTargetSource now just call =
getType(name) to determine the target class, with a singleton or =
prototype target. Note that getType is allowed to return null, just like =
FactoryBean.getObjectType(), if it is not able to determine a proper =
result class. The caller can then resort to getBean(name).getClass(), =
creating a new prototype just for this; this is the caller's decision.

Furthermore, I've added a "getBeansOfType(type)" convenience method to =
ListableBeanFactory, matching all kinds of bean types. This is what most =
callers will want to do, so it makes sense to offer this as a simplified =
version (just like we do for getBean or getBeanDefinitionNames). =
"getBeansOfType(type, includePrototypes, includeFactoryBeans)" still =
allows for further customization of the result.

Those changes should be perfectly backwards-compatible from an API point =
of view. Just BeanFactory implementors will have to implement the new =
methods, when compiling against the new Spring version. However, I =
assume that hardly anyone implements custom bean factories that do not =
extend from Spring's base classes...

Essentially, the BeanFactory interface is an API, not an SPI, from a =
backwards compatibility perspective, similar to JDBC or the J2EE =
interfaces. Compare JDO 1.0.1, which introduced =
PersistenceManager.close: perfectly backwards-compatible from an API =
point of view, but requires implementors to provide the new "close" =
method when compiling against the new API version.

Juergen