spring-framework

Spring Framework

Tree: c6a0f1ef25

Chris Beams 91f05c8b9d Avoid creation of unnecessary Environment objects Prior to this change, any instantiation of an AnnotationConfigApplicationContext would trigger the creation of three StandardEnvironment objects: one for the ApplicationContext, one for the AnnotatedBeanDefinitionReader, and one for the ClassPathBeanDefinitionScanner. The latter two are immediately swapped out when the ApplicationContext delegates its environment to these subordinate objects anyway. Not only is it inefficient to create these two extra Environments, it creates confusion when debug-level logging is turned on. From the user's perspective and in practice, there is only one Environment; logging should reflect that. This change ensures that only one Environment object is ever created for a given ApplicationContext. If an AnnotatedBeanDefinitionReader or ClassPathBeanDefinitionScanner are used in isolation, e.g. against a plain BeanFactory/BeanDefinitionRegistry, then they will still create their own local StandardEnvironment object. All public API compatibility is preserved; new constructors have been added where necessary to accommodate passing an Environment directly to ABDR ar CPBDS.	15 years ago
..
main	Avoid creation of unnecessary Environment objects	15 years ago
test	Use 'name' vs 'key' consistently in PropertySource	15 years ago

Chris Beams 91f05c8b9d Avoid creation of unnecessary Environment objects

Prior to this change, any instantiation of an
AnnotationConfigApplicationContext would trigger the creation of three
StandardEnvironment objects: one for the ApplicationContext, one for the
AnnotatedBeanDefinitionReader, and one for the
ClassPathBeanDefinitionScanner.

The latter two are immediately swapped out when the ApplicationContext
delegates its environment to these subordinate objects anyway. Not only
is it inefficient to create these two extra Environments, it creates
confusion when debug-level logging is turned on. From the user's
perspective and in practice, there is only one Environment; logging
should reflect that.

This change ensures that only one Environment object is ever created for
a given ApplicationContext. If an AnnotatedBeanDefinitionReader or
ClassPathBeanDefinitionScanner are used in isolation, e.g. against a
plain BeanFactory/BeanDefinitionRegistry, then they will still create
their own local StandardEnvironment object.

All public API compatibility is preserved; new constructors have been
added where necessary to accommodate passing an Environment directly
to ABDR ar CPBDS.

15 years ago

main

Avoid creation of unnecessary Environment objects

15 years ago

test

Use 'name' vs 'key' consistently in PropertySource

15 years ago