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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4600 50f2f4bb-b051-0410-bef5-90022cba6387
- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4573 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4568 50f2f4bb-b051-0410-bef5-90022cba6387
Prior to this change, the Property class introduced in 3.1 M2 validated
read/write property method pairs based on whether their parameter/return
types were equal to one another. This precluded the valid possibility
of read method that returns a subtype of the write method's parameter
type, and represented a regression against 3.1 M1 and earlier versions.
The implementation now uses isAssignableFrom rather than a straight
equals check against the types.
Issue: SPR-8432
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4561 50f2f4bb-b051-0410-bef5-90022cba6387
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
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4560 50f2f4bb-b051-0410-bef5-90022cba6387
Prior to this change, DirectFieldAccessor would ignore fields shadowed
in subclasses, favoring the last field processed, which happens to be
the most super declaration based on the way ReflectionUtils.doWithFields
works.
Because the locally shadowed field may be of a different type that the
superclass declaration, it is most correct to preserve and work with
the shadowed field.
Issue: SPR-8398
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4559 50f2f4bb-b051-0410-bef5-90022cba6387
Sam Brannen
Rossen Stoyanchev
Chris Beams
David Syer
Arjen Poutsma
Juergen Hoeller