Refactor ConfigurationClassParser to recursively find values from
all @Import annotations, combining them into a single unique set.
This change prevents ImportBeanDefinitionRegistrars from being
invoked twice.
Issue: SPR-9925
Backport-Commit: 6d8b37d8bb
Conflicts:
spring-context/src/main/java/org/springframework/context/annotation/ConfigurationClassParser.java
JDK 5 introduced an XML-based properties file syntax. This commit
ensures that when such files are supplied as the underlying resource
for a ResourcePropertySource instance, they are routed appropriately
to Properties#loadFromXML as opposed to Properties#load.
Issue: SPR-9896
Backport-Commit: 3a626f9319
Prior to this change, CachedIntrospectionResults delegated to
ExtendedBeanInfo by default in order to inspect JavaBean
PropertyDescriptor information for bean classes.
Originally introduced with SPR-8079, ExtendedBeanInfo was designed to
go beyond the capabilities of the default JavaBeans Introspector in
order to support non-void returning setter methods, principally to
support use of builder-style APIs within Spring XML. This is a complex
affair, and the non-trivial logic in ExtendedBeanInfo has led to various
bugs including regressions for bean classes that do not declare
non-void returning setters.
Many of these issues were fixed when overhauling non-void JavaBean write
method support in SPR-10029, however it appears that some extremely
subtle issues may still remain. ExtendedBeanInfo was taken out of use
completely in the 3.2.x line with SPR-9677 and the new BeanInfoFactory
mechanism. This support was not backported to 3.1.x, however, in the
interest of stability.
This commit, then, inlines the conditional logic introduced by
BeanInfoFactory directly into CachedIntrospectionResults. The net effect
is that ExtendedBeanInfo is out of the code path entirely except for
bean classes that actually contain 'candidate' methods, i.e. non-void
and/or static write methods.
This commit also includes the changes made in SPR-10115.
Issue: SPR-9723, SPR-10029, SPR-9677, SPR-8079
Some servlet containers (iPlanet) parse the Accept header and return
multiple values from request.getHeader("Accept"). The HttpHeaders
getAccept method has been updated to accommodate that hopefully
without causing any other issues.
The extra functionality is in effect only if we find only one
MediaType and there is more than one value for the 'Accept' header.
Issue: SPR-9655
Revert ReflectivePropertyAccessor changes from 107fafb and instead
consider all methods when resolving properties. Methods are now
sorted such that non-bridge methods are considered before bridge
methods.
Issue: SPR-10162
Backport-Commit: fce7adc400
Replace reference to aspectjrt.jar with aspectjweaver.jar since
aspectjrt is a subset of aspectjweaver and the full jar is required
by Spring.
Issue: SPR-8896
Backport-Commit: d70762baaf
This change resolves a specific issue with processing
java.math.BigDecimal via ExtendedBeanInfo. BigDecimal has a particular
constellation of #setScale methods that, prior to this change, had the
potential to cause ExtendedBeanInfo to throw an IntrospectionException
depending on the order in which the methods were processed.
Because JDK 7 no longer returns deterministic results from
Class#getDeclaredMethods, it became a genuine possibility - indeed a
statistical certainty that the 'wrong' setScale method handling order
happens sooner or later. Typically one could observe this failure once
out of every four test runs.
This commit introduces deterministic method ordering of all discovered
non-void returning write methods in such a way that solves the problem
for BigDecimal as well as for any other class having a similar method
arrangement.
Also:
- Remove unnecessary cast
- Pass no method information to PropertyDescriptor superclasses when
invoking super(...). This ensures that any 'type mismatch'
IntrospectionExceptions are handled locally in ExtendedBeanInfo and
its Simple* PropertyDescriptor variants where we have full control.
Issue: SPR-10111, SPR-9702
