This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses. See Javadoc and existing implementations for detail.
Issue: SPR-8354
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4335 50f2f4bb-b051-0410-bef5-90022cba6387
AbstractEnvironment and subclasses now register a reserved default
profile named literally 'default' such that with no action on the part
of the user, beans defined against the 'default' profile will be
registered - if no other profiles are explicitly activated.
For example, given the following three files a.xml, b.xml and c.xml:
a.xml
-----
<beans> <!-- no 'profile' attribute -->
<bean id="a" class="com.acme.A"/>
</beans>
b.xml
-----
<beans profile="default">
<bean id="b" class="com.acme.B"/>
</beans>
c.xml
-----
<beans profile="custom">
<bean id="c" class="com.acme.C"/>
</beans>
bootstrapping all of the files in a Spring ApplicationContext as
follows will result in beans 'a' and 'b', but not 'c' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // true
ctx.containsBean("c"); // false
whereas activating the 'custom' profile will result in beans 'a' and
'c', but not 'b' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.getEnvironment().setActiveProfiles("custom");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // false
ctx.containsBean("c"); // true
that is, once the 'custom' profile is activated, beans defined against
the the reserved default profile are no longer registered. Beans not
defined against any profile ('a') are always registered regardless of
which profiles are active, and of course beans registered
against specific active profiles ('c') are registered.
The reserved default profile is, in practice, just another 'default
profile', as might be added through calling env.setDefaultProfiles() or
via the 'spring.profiles.default' property. The only difference is that
the reserved default is added automatically by AbstractEnvironment
implementations. As such, any call to setDefaultProfiles() or value set
for the 'spring.profiles.default' will override the reserved default
profile. If a user wishes to add their own default profile while
keeping the reserved default profile as well, it will need to be
explicitly redeclared, e.g.:
env.addDefaultProfiles("my-default-profile", "default")
The reserved default profile(s) are determined by the value returned
from AbstractEnvironment#getReservedDefaultProfiles(). This protected
method may be overridden by subclasses in order to customize the
set of reserved default profiles.
Issue: SPR-8203
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4334 50f2f4bb-b051-0410-bef5-90022cba6387
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4326 50f2f4bb-b051-0410-bef5-90022cba6387
Revert signature of
ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form
found in the 3.0.x line. Refactorings made during 3.1 development
caused otherwise package-private types such as
ConfigurationClassBeanDefinitionReader to escape through this public
method, causing issues for STS as well as being a general design issue.
Upon review, the refactorings could easily be backed out in favor of a
simpler approach, and this has been done.
This also means that ConfigurationClassBeanDefinitionReader can return
to package-private visibility, and this change has been made as well.
Issue: SPR-8200
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4322 50f2f4bb-b051-0410-bef5-90022cba6387
- eliminate unneeded methods
+ introduced value wrapper (name still to be decided) to avoid cache race conditions
+ improved name consistency
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4315 50f2f4bb-b051-0410-bef5-90022cba6387
@Autowired, @Value and other annotations cannot be applied within
Spring Bean(Factory)PostProcessor types, because they themselves
are processed using BeanPostProcessors. Javadoc and reference docs
have been updated to reflect.
Issue: SPR-4935, SPR-8213
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4300 50f2f4bb-b051-0410-bef5-90022cba6387
A subtle issue existed with the way we relied on isCurrentlyInCreation
to determine whether a @Bean method is being called by the container
or by user code. This worked in most cases, but in the particular
scenario laid out by SPR-8080, this approach was no longer sufficient.
This change introduces a ThreadLocal that contains the factory method
currently being invoked by the container, such that enhanced @Bean
methods can check against it to see if they are being called by the
container or not. If so, that is the cue that the user-defined @Bean
method implementation should be invoked in order to actually create
the bean for the first time. If not, then the cached instance of
the already-created bean should be looked up and returned.
See ConfigurationClassPostConstructAndAutowiringTests for
reproduction cases and more detail.
Issue: SPR-8080
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4296 50f2f4bb-b051-0410-bef5-90022cba6387
If the enclosing environment does not implement ConfigurableEnvironment,
then @PropertySource annotations are ignored because there is no way to
add them to the Environment. Now checking first to see if there are any
@PropertySource annotations present before issuing the warning.
Issue: SPR-8314
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4295 50f2f4bb-b051-0410-bef5-90022cba6387
Allows a convenient mechanism for contributing a PropertySource to the
enclosing Spring Environment. See @PropertySource Javadoc for
complete details and PropertySourceAnnotationTests for examples.
Issue: SPR-8314
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4289 50f2f4bb-b051-0410-bef5-90022cba6387
Allows convenient creation of a Properties-based PropertySource from a
Spring Resource object or resource location string such as
"classpath:com/myco/app.properties" or "file:/path/to/file.properties"
Issue: SPR-8328
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4288 50f2f4bb-b051-0410-bef5-90022cba6387
Chris Beams
Rossen Stoyanchev
Arjen Poutsma
Costin Leau
Oliver Gierke
Andy Clement
Sam Brannen