This subinterface of BeanFactory is not meant to be used in normal application code: Stick to BeanFactory or ListableBeanFactory for typical use cases. This interface is just meant to allow for framework-internal plug'n'play even when needing access to bean factory configuration methods.
| Method Summary | |
|---|---|
| void |
Add a new BeanPostProcessor that will get applied to beans created by this factory. |
| boolean |
Check if this bean factory contains a singleton instance with the given name. |
| void |
Destroy all cached singletons in this factory. |
| int |
Return the current number of registered BeanPostProcessors. |
| void |
Given a bean name, create an alias. |
| void |
Register the given custom property editor for all properties of the given type. |
| void |
Register the given existing object as singleton in the bean factory, under the given bean name. |
| void |
Set the parent of this bean factory. |
| Methods inherited from org.springframework.beans.factoryBeanFactory |
|---|
| Methods inherited from org.springframework.beans.factoryHierarchicalBeanFactory |
|---|
The main purpose of this method is to check manually registered singletons
(see registerSingleton). Can also be used to check whether a
singleton defined by a bean definition has already been created.
To check whether a bean factory contains a bean definition with a given name,
use ListableBeanFactory's containsBeanDefinition. Analogous to the
present method, this checks whether the factory contains a registered bean definition.
Note that both of those methods check for the actual given bean name, ignoring aliases.
Use BeanFactory's containsBean for general checks whether the
factory knows about a bean with a given name (whether manually registed singleton
instance or created by bean definition), also checking ancestor factories. To check
the local factory only, use HierarchicalBeanFactory's containsLocalBean.
Both of those methods translate aliases back to the corresponding canonical bean name.
public
void
destroySingletons
(
)
public
int
getBeanPostProcessorCount
(
)
Typically invoked during factory configuration, but can also be used for runtime registration of aliases. Therefore, a factory implementation should synchronize alias access.
The given instance is supposed to be fully initialized; the factory
will not perform any initialization callbacks (in particular, it won't
call InitializingBean's afterPropertiesSet method).
The given instance will not receive any destruction callbacks
(like DisposableBean's destroy method) either.
Register a bean definition instead of an existing instance if your bean is supposed to receive initialization and/or destruction callbacks.
Typically invoked during factory configuration, but can also be used for runtime registration of singletons. Therefore, a factory implementation should synchronize singleton access; it will have to do this anyway if it supports lazy initialization of singletons.
Note that the parent shouldn't be changed: It should only be set outside a constructor if it isn't available when an object of this class is created.
