Prior to this change, an assumption was made in
AbstractAutowireCapableBeanFactory that any factory-method would have
zero parameters. This may not be the case in @Bean methods.
We now look for the factory-method by name in a more flexible fashion
that accomodates the possibility of method parameters.
There remains at least one edge cases here where things could still fail,
for example a @Configuration class could have two FactoryBean-returning
methods of the same name, but each with different generic FactoryBean
types and different parameter lists. In this case, the implementation
may infer and return the wrong object type, as it currently returns
the first match for the given factory-method name. The complexity cost
of ensuring that this never happens is not likely worth the trouble
given the very low likelihood of such an arrangement.
Issue: SPR-8762
Properties such as 'spring.profiles.active' cannot be specified at the
command line under Bash and other shells due to variable naming
constraints. This change allows for exchanging underscores for periods
as well as capitalizing property names for more idiomatic naming when
dealing with environment variables.
For example, Spring will respect equally either of the following:
spring.profiles.active=p1 java -classpath ... MyApp
SPRING_PROFILES_ACTIVE=p1 java -classpath ... MyApp
The former is not possible under Bash, while the latter is. No code or
configuration changes are required; SystemEnvironmentPropertySource
adapts for these varations automatically.
SystemEnvironmentPropertySource is added by default as
"systemEnvironment" to StandardEnvironment and all subtypes, taking the
place of the plain MapPropertySource that was in use before this change.
Issue: SPR-8869
Currently the combine method consolidates "/*" and "/hotel"
into "/hotel". However if the first pattern contains URI template
variables, the consolidation seems wrong. The fix is to prevent
the consolidation if the first pattern contains "{".
Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
distinguish between (a) bridge methods introduced in Java 6 to
compensate for inheriting public methods from non-public superclasses
and (b) bridge methods that have existed since Java 5 to accommodate
return type covariance and generic parameters.
In the former case, annotations should be looked up from the original
bridged method (SPR-7900). In the latter, the annotation should be
looked up against the bridge method itself (SPR-8660).
As noted in the Javadoc for the new method, see
http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
for a useful description of the various types of bridge methods, as
well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
Java 6 resulting in the introduction of 'visibility bridge methods'.
Issue: SPR-8660, SPR-7900
Remove all convenience variants of #findAllAnnotationAttributes and
refactor the remaining method to accept a MetadataReaderFactory
instead of creating its own SimpleMetadataReaderFactory internally.
This allows clients to use non-default class loaders as well as
customize the particular MetadataReaderFactory to be used (e.g.
'simple' vs 'caching', etc).
Issue: SPR-8752
Provides a convenient mechanism for activating an additional profile
while preserving those that are already active, as opposed to
calling #setActiveProfiles with the contents of #getActiveProfiles plus
the new profile.
Issue: SPR-8548
