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
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.
Sam Brannen added a comment - 13/Sep/07 05:57 AM Hi Costin,
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.
Improvement
Resolved
Major
AbstractSingleSpringContextTests bean definition reader
Hi Costin,
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:
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.