
|
If you were logged in you would be able to see more operations.
|
|
|
|
AbstractSingleSpringContextTests always uses an Xml Bean definition reader internally when creating the application context inside createApplicationContext().
It would be nice to have the bean definition reader creation in a separate methods so that subclasses can chose that individually w/o copy-pasting createApplicationContext() to do the context creation and refresh.
Consider JavaConfig where an Annotation based reader can be plugged in. I assume the same holds true for Spring 2.1
|
|
Description
|
AbstractSingleSpringContextTests always uses an Xml Bean definition reader internally when creating the application context inside createApplicationContext().
It would be nice to have the bean definition reader creation in a separate methods so that subclasses can chose that individually w/o copy-pasting createApplicationContext() to do the context creation and refresh.
Consider JavaConfig where an Annotation based reader can be plugged in. I assume the same holds true for Spring 2.1 |
Show » |
|
AbstractSingleSpringContextTests has been retrofitted with a createBeanDefinitionReader()
method which returns an XmlBeanDefinitionReader by default. Subclasses may override
createBeanDefinitionReader() to provide a different BeanDefinitionReader implementation
as necessary.
If you'd like to see a concrete example in action, feel free to check out the unit tests
associated with this issue which demonstrate usage with the default XmlBeanDefinitionReader
and a PropertiesBeanDefinitionReader. You will find these tests in upcoming snapshots:
- XmlBasedSpr3350SingleSpringContextTests
- PropertiesBasedSpr3350SingleSpringContextTests
cheers,
Sam
p.s. please note that the new Spring TestContext Framework also supports custom loading of
ApplicationContexts out-of-the-box via the ContextLoader strategy interface and two concrete
implementations: GenericXmlContextLoader and GenericPropertiesContextLoader.