Prior to this change, @Autowired injection against an instance of a
subclass having different visibility than its superclass would fail
if the @Autowired method is declared only in the superclass. This is due
to an apparent change in the rules around bridge method generation
between Java 5 and Java 6, and possibly even varying across compiler
vendors.
Now, BridgeMethodResolver is used consistently when detecting
@Autowired, @Inject and @Resource metadata to bypass these bridge
methods if they exist.
Issue: SPR-7900
Prior to this change, AbstractAutowireCapableBeanFactory did not support
a default ParameterNameDiscoverer. This meant that attempting to use
<constructor-arg name=".."> syntax would fail (with a fairly obscure
exception) as that feature depends on a ParameterNameDiscoverer to
introspect the constructor arguments.
This lack of a default was originally intended to avoid a dependency on
ASM, but now that (a) .asm is a built-in module and (b) .beans has a
non-optional compile-time dependency on .asm, there is no reason not to
provide this default.
The net effect is that in a number of locations throughout the
framework, namely in GenericApplicationContext and
AbstractRefreshableApplicationContext, it is no longer necessary to
explicitly call AACBF#setParameterNameDiscoverer. This also means that
using a naked BeanFactory (likely for testing scenarios) is that much
easier.
Issue: SPR-8184
As of SPR-8093, jmxremote_optional.jar is present on the build
server in jre/lib/ext, but it is not by default present on local
developer / user machines, meaning that the build ends up broken
by default.
Issue: SPR-8089, SPR-8093, SPR-8458
+ remove generic signature on key generator (as the type is not used anywhere)
+ add a small improvement to CacheAspect to nicely handle the cases where the aspect is pulled in but not configured
ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @Order usage; previously
supported only implementation of the Ordered interface.
Calls to AbstractApplicationContext#setParent delegate the parent
context environment to the child.
This ensures that any property sources added to the parent are available
to the child as well as ensuring that any profiles activated are
activated everywhere.
Child contexts may still choose to replace their environment (through an
ApplicationContextInitializer, for example). In any case, however, in
the root/child web application context relationship established by
ContextLoader + DispatcherServlet, the child is guaranteed to have
already been given the parent environment by the time it is delegated
to any ACIs.
See AbstractApplicationContext#setParent for implementation
See FrameworkServlet#createWebApplicationContext for order in which
setParent then initializeWebApplicationContext are called.
Issue: SPR-8185
AnnotationConfigApplicationContext and
AnnotationConfigWebApplicationContext both expose #register and #scan
methods as of the completion of SPR-8320. This change introduces a new
interface that declares each of these methods and refactors ACAC and
ACWAC to implement it.
Beyond information value, this is useful for implementors of the
ApplicationContextInitializer interface, in that users may create an ACI
that works consistently across ACAC and ACWAC for standalone (e.g.
testing, batch) or web (e.g. production) use.
Issue: SPR-8365,SPR-8320
FrameworkServlet now has support equivalent to ContextLoader and its
"contextInitializerClasses" context-param introduced in 3.1 M1.
This allows users to specify ApplicationContextInitializers at the root
(ContextLoader) level and/or at the DispatcherServlet level.
Issue: SPR-8366
The following is now possible:
@Configuration
public class AppConfig {
@Inject DataSource dataSource;
@Bean
public MyBean myBean() {
return new MyBean(dataSource);
}
@Configuration
static class DatabaseConfig {
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().build();
}
}
}
public static void main(String... args) {
AnnotationConfigApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
ctx.getBean(MyBean.class); // works
ctx.getBean(DataSource.class); // works
}
Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.
See @Configuration Javadoc for details.
Issue: SPR-8186
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
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
David Syer
Juergen Hoeller
Chris Beams
Sam Brannen
Mark Fisher
Oliver Gierke
Costin Leau
Keith Donald