MapToMap conversion now works when the target map does not have a
default constructor (as long as a new map copy is not required).
Issue: SPR-9284
Backport-Commit: 38c4393592
Refactor ConfigurationClassEnhancer to allow cglib caching of
generated classes. Prior to this commit each enhanced @Configuration
class would consume permgen space when created.
The CallbackFilter and Callback Types are now defined as static final
members so that they can be shared by all enhancers. Only the
callbackInstances remain specific to a @Configuration class and
these are not used by cglib as part of the cache key.
Issue: SPR-9851
Backport-Commit: c8061393fb
Update the ReflectiveMethodResolver and ReflectivePropertyAccessor
to allow methods and properties of java.lang.Class to be resolved
when the target object is a class.
Issue: SPR-9017
Backport-Commit: d28592a6c6
SpringEL300Tests's #testArray method was originally introduced with
SPR-9203, which has not yet been backported to 3.1.x. During the process
of backporting SPR-9486 functionality, this method was accidentally
introduced, causing false negative test failures. This commit removes
the offending test method.
Issue: SPR-9203, SPR-9486
This change ensures that SpEL expressions involving floats are
supported natively as opposed to the previous behavior which required
conversion to double, leading to potential downstream conversion
ambiguities.
Issue: SPR-9486
Backport-Commit: be8f23d756
Previously UriComponentsBuilder used a regular expression for parsing
query name-value pairs where both name and value were expected to not
contain neither '&', not '='. The idea is that the presence of reserved
characters makes it impossible to guess correctly how to parse the
query string (e.g. a=b&c).
This change relaxes the constraint on query param values, allowing them
to contain '='. In effect '&' is the ultimate separator of name-value
pairs, and any '=' in values is ignored. For example "q=1USD=?EUR" is
interpreted as "q equals '1USD=?EUR'".
Issue: SPR-9832
The target parameters for a FlashMap must be decoded to be able to
match them to the parameters of incoming requests given that the
HttpServletRequest returns decoded request parameters.
Issue: SPR-9657
Backport Issue: SPR-9701
The ErrorsMethodArgumentResolver expects the preceding @ModelAttribute
in the controller method signature to be the last one added in the
model -- an assumption that can break if a model attribute is added
earlier (e.g. through a @ModelAttribute method) and more attributes
are added as well. This fix ensures when an @ModelAttribute is resolved
as a controller method argument it has the highest index in the model.
Issue: SPR-9378
Backport Issue: SPR-9687
Prior to this commit spring-web's dependence on spring-aop was marked
optional, however spring-web's required dependence on spring-context
transitively forces a required dependence on spring-aop anyway.
This change marks spring-aop as a required dependency of spring-web,
which a) reflects the poms created by the 3.2 Gradle build and b) helps
solve dependency issues when using higher-level Spring projects such as
Spring Security.
Issue: SPR-9573
Reverted change for @Bean methods that declare FactoryBean as their return type: The effects of trying to create the FactoryBean to find out about its implementation type are too far-reaching. It's better to recommend declaring a specific return type in the method signature if you want the container to specifically react to your implementation type.
Issue: SPR-9857
Includes a change for factory methods that declare their return type as FactoryBean: When asked for a specific type match (e.g. LoadTimeWeaverAware), we do check early singleton instances as well (reusing the instances that we create for getObjectType checks). This is necessary in order to make @Bean method introspection as capable as XML bean definition introspection, even in case of the @Bean method using a generic FactoryBean declaration for its return type (instead of the FactoryBean impl class).
Issue: SPR-9857
Includes a change for factory methods that declare their return type as FactoryBean: When asked for a specific type match (e.g. LoadTimeWeaverAware), we do check early singleton instances as well (reusing the instances that we create for getObjectType checks). This is necessary in order to make @Bean method introspection as capable as XML bean definition introspection, even in case of the @Bean method using a generic FactoryBean declaration for its return type (instead of the FactoryBean impl class).
Issue: SPR-9857
This change ensures that when the Accept and the Producible media types
are equally specific, we use the one from the Accept header, which may
for example carry a different charset.
Previously, the spring-web pom still depended on the EBR-style
com.springsource artifactId for hessian.
It now depends on Maven Central-style com.caucho:hessian:3.2.1 naming.
Note that Hessian 3.2.1 acutally does not exist in Maven Central, but is
present in the SpringSource repository at http://repo.springsource.org.
In any case, the dependency is optional, so should not cause issues at
build time for applications dependent on spring-web.
Issue: SPR-9854
This change fixes further cases under JDK 6 in which setting a bridged
(e.g. String-returning) read method can conflict with an existing
corresponding bridge write method that accepts an Object parameter.
This appears to be a implementation difference between JDKs 6 and 7,
where the JDK 6 Introspector adds bridge methods and JDK 7 does not.
The solution here is to consistently null-out any existing write method
before setting the read method. We were doing this elsewhere in
ExtendedBeanInfo already, but these two changes make the approach
consistent throuhout.
Issue: SPR-8806
Backport-Commit: 0c0a563a24
- Ensure that ExtendedBeanInfoTests succeeds when building under JDK 7
- Improve handling of read and write method registration where
generic interfaces are involved, per SPR-9453
- Add repro test for SPR-9702, in which EBI fails to register
an indexed read method under certain circumstances
Issue: SPR-9778
Backport-Issue: SPR-9702, SPR-9414, SPR-9453
Backport-Commit: b50bb5071a
Caching of resovled exceptions introduced in SPR-7703 also introduced a
side effect whereby if exactly one exception was previously cached, any
other exception would appear as a match to the previously matched
@ExceptionHandler method.
This change ensures use of a fresh map when determining matching
@ExceptionHandler methods while also updating the cache.
Issue: SPR-9209
An additional update (after the last commit) of the "includes" and
"isCompatibleWith" methods of MediaType to accomodate wildcards
in media types with a suffix.
Issue: SPR-9841
The "includes" and "isCompatibleWith" methods of MediaType take into
account media types with suffices (e.g. application/soap+xml) including
wildcards with suffices (e.g. application/*+xml). However before this
change, the isWildcardSubtype() method returned true only for subtype
"*". Now a media type such as application/*+xml is also recognized as
having a wildcard subtype.
Issue: SPR-9841
This should be significantly faster than our standard algorithm, for a very common case. Motivated by SPR-9802, even if the fix there uses a different approach, with transaction name determination not calling getMostSpecificMethod at all anymore.
Issue: SPR-9802
As of Spring 3.0.4, we were trying to expose the target method signature as transaction name. Unfortunately, the algorithm called the ClassUtils.getMostSpecificMethod helper method which performs a quite expensive reflective search. As of this commit, we're simply concatenating the target class name with the method name, accepting the use of the concrete target class (which is arguably more meaningful for monitoring anyway) even when the method implementation actually sits on a base class.
Issue: SPR-9802
These features require Java 6 or higher due to their dependency on the ResourceBundle.Control class. To some degree, ResourceBundleMessageSource catches up with ReloadableResourceBundleMessageSource now. However, as noted in the javadoc, there are still severe limitations in the standard ResourceBundle class that justify an ongoing investment in our own ReloadableResourceBundleMessageSource (based on the Spring resource abstraction, with manual parsing of properties files).
Issue: SPR-7392
