Recent changes in ExtendedBeanInfo involve invoking
ClassUtils#getMostSpecificMethod when determining JavaBeans get/set
pairs; if Java security settings control disallow reflective access,
this results in an AccessControlException.
This change defends against this (comparatively rare) scenario by
catching the exception and falling back to returning the method
originally supplied by the user.
This change was a result of noticing CallbacksSecurityTests failing
following the ExtendedBeanInfo modifications mentioned above
Issue: SPR-8949
Prior to this commit, and due to idiosyncracies of
java.beans.Introspector, overridden boolean getter methods were not
detected by Spring's ExtendedBeanInfo, which relied on too-strict
Method equality checks when selecting read and write methods.
Now ExtendedBeanInfo uses Spring's ClassUtils#getMostSpecificMethod
against the methods returned from java.beans.Introspector in order
to ensure that subsequent equality checks are reasonable to make.
Issue: SPR-8949
ServletServerHttpRequest now falls back on the contentType and the
the characterEncoding of the ServletRequest, if the headers of the
incoming request don't specify one. Similary ServletServerHttpResponse
sets the contentType and the characterEncoding of the ServletResponse
if not already set.
This allows using the CharacterEncodingFilter to set a character
encoding where the request doesn't specify one and have it be used
in HttpMessageConverter's.
SPR-9096
Although the reference documentation listed the new @MVC support
classes and their benefits, it did not explicitly mention a few
use cases that are no longer supported. There is now a specific
section on the new support classes listing exactly what is not
supported.
Similary the @RequestMapping annotation never refered explicitly
to the existence of old and new support and never made it clear
exactly what the differences are.
Both have not been corrected.
SPR-9063, SPR-9042
Uses of AnnotationMetadata#getAnnotationAttributes throughout the
framework have been updated to use the new AnnotationAttributes API in
order to take advantage of the more concise, expressive and type-safe
methods there.
All changes are binary compatible to the 3.1.0 public API, save
the exception below.
A minor binary compatibility issue has been introduced in
AbstractCachingConfiguration, AbstractAsyncConfiguration and
AbstractTransactionManagementConfiguration when updating their
protected Map<String, Object> fields representing annotation attributes
to use the new AnnotationAttributes API. This is a negligible breakage,
however, as the likelilhood of users subclassing these types is very
low, the classes have only been in existence for a short time (further
reducing the likelihood), and it is a source-compatible change given
that AnnotationAttributes is assignable to Map<String, Object>.
Background
Spring 3.1 introduced the @ComponentScan annotation, which can accept
an optional array of include and/or exclude @Filter annotations, e.g.
@ComponentScan(
basePackages = "com.acme.app",
includeFilters = { @Filter(MyStereotype.class), ... }
)
@Configuration
public class AppConfig { ... }
@ComponentScan and other annotations related to @Configuration class
processing such as @Import, @ImportResource and the @Enable*
annotations are parsed using reflection in certain code paths, e.g.
when registered directly against AnnotationConfigApplicationContext,
and via ASM in other code paths, e.g. when a @Configuration class is
discovered via an XML bean definition or when included via the
@Import annotation.
The ASM-based approach is designed to avoid premature classloading of
user types and is instrumental in providing tooling support (STS, etc).
Prior to this commit, the ASM-based routines for reading annotation
attributes were unable to recurse into nested annotations, such as in
the @Filter example above. Prior to Spring 3.1 this was not a problem,
because prior to @ComponentScan, there were no cases of nested
annotations in the framework.
This limitation manifested itself in cases where users encounter
the ASM-based annotation parsing code paths AND declare
@ComponentScan annotations with explicit nested @Filter annotations.
In these cases, the 'includeFilters' and 'excludeFilters' attributes
are simply empty where they should be populated, causing the framework
to ignore the filter directives and provide incorrect results from
component scanning.
The purpose of this change then, is to introduce the capability on the
ASM side to recurse into nested annotations and annotation arrays. The
challenge in doing so is that the nested annotations themselves cannot
be realized as annotation instances, so must be represented as a
nested Map (or, as described below, the new AnnotationAttributes type).
Furthermore, the reflection-based annotation parsing must also be
updated to treat nested annotations in a similar fashion; even though
the reflection-based approach has no problem accessing nested
annotations (it just works out of the box), for substitutability
against the AnnotationMetadata SPI, both ASM- and reflection-based
implementations should return the same results in any case. Therefore,
the reflection-based StandardAnnotationMetadata has also been updated
with an optional 'nestedAnnotationsAsMap' constructor argument that is
false by default to preserve compatibility in the rare case that
StandardAnnotationMetadata is being used outside the core framework.
Within the framework, all uses of StandardAnnotationMetadata have been
updated to set this new flag to true, meaning that nested annotation
results will be consistent regardless the parsing approach used.
Spr9031Tests corners this bug and demonstrates that nested @Filter
annotations can be parsed and read in both the ASM- and
reflection-based paths.
Major changes
- AnnotationAttributes has been introduced as a concrete
LinkedHashMap<String, Object> to be used anywhere annotation
attributes are accessed, providing error reporting on attribute
lookup and convenient type-safe access to common annotation types
such as String, String[], boolean, int, and nested annotation and
annotation arrays, with the latter two also returned as
AnnotationAttributes instances.
- AnnotationUtils#getAnnotationAttributes methods now return
AnnotationAttributes instances, even though for binary compatibility
the signatures of these methods have been preserved as returning
Map<String, Object>.
- AnnotationAttributes#forMap provides a convenient mechanism for
adapting any Map<String, Object> into an AnnotationAttributes
instance. In the case that the Map is already actually of
type AnnotationAttributes, it is simply casted and returned.
Otherwise, the map is supplied to the AnnotationAttributes(Map)
constructor and wrapped in common collections style.
- The protected MetadataUtils#attributesFor(Metadata, Class) provides
further convenience in the many locations throughout the
.context.annotation packagage that depend on annotation attribute
introspection.
- ASM-based core.type.classreading package reworked
Specifically, AnnotationAttributesReadingVisitor has been enhanced to
support recursive reading of annotations and annotation arrays, for
example in @ComponentScan's nested array of @Filter annotations,
ensuring that nested AnnotationAttributes objects are populated as
described above.
AnnotationAttributesReadingVisitor has also been refactored for
clarity, being broken up into several additional ASM
AnnotationVisitor implementations. Given that all types are
package-private here, these changes represent no risk to binary
compatibility.
- Reflection-based StandardAnnotationMetadata updated
As described above, the 'nestedAnnotationsAsMap' constructor argument
has been added, and all framework-internal uses of this class have
been updated to set this flag to true.
Issue: SPR-7979, SPR-8719, SPR-9031
Ensure that both FlashMapManager methods - the one invoked at the
start of a request and the one invoked before a redirect, update
the underlying storage fully since it's not guaranteed that both
will be invoked on any given request.
Also move the logic to remove expired FlashMap instances to the
metohd invoked at the start of a request to ensure the check is
made frequently enough.
SPR-8997
Prior to this change, single quotes were incorrectly parsed by
NamedParameterUtils#parseSqlStatement, resulting in incorrect parameter
counts:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 0 // incorrect, misses :xxx
That is, presence of the single-quoted string caused the parser to
overlook the named parameter :xxx.
This commit fixes the parsing error such that:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 1 // correct
Issue: SPR-8280
ResourceDatabasePopulator is a component that underlies the database
initialization support within Spring's jdbc: namespace, e.g.:
<jdbc:initialize-database data-source="dataSource">
<jdbc:script execution="INIT" location="classpath:init.sql"/>
</jdbc:initialize-database>
Prior to this commit, ResourceDatabasePopulator#executeSqlScript's use
of Statement#executeUpdate(sql) precluded the possibility of SELECT
statements because returning a result is not permitted by this method
and results in an exception being thrown.
Whether this behavior is a function of the JDBC specification or an
idiosyncracy of certain implementations does not matter as the issue
can be worked around entirely. This commit eliminates use
of #executeUpdate(sql) in favor of #execute(sql) followed by a call
to #getUpdateCount, effectively allowing any kind of SQL statement to
be executed during database initialization.
Issue: SPR-8932
Prior to this commit, StandardServletEnvironment's servlet context
PropertySource remained stubbed out until it the ServletContext became
available and could be replaced during the refresh() of its enclosing
WebApplicationContext. This behavior is acceptable in most cases.
However, if the user has declared an ApplicationContextInitializer that
attempts to access servlet context-params via the Environment API, this
result in a kind of 'false negative', i.e. the context-param key and
value are actually present in the ServletContext, but the PropertySource
representing servlet context params is still a stub at this point,
meaning that it returns an empty result in all cases.
With this change, WebApplicationContextUtils#initServletPropertySources
is invoked eagerly by the ContextLoader if any ACI classes have been
declared. This swaps out the servlet context property source stub for
the real thing just in time for ACIs to use it if necessary.
Extra guard logic has been added to #initServletPropertySources to
ensure idempotency -- once the stub has been replaced, the method
never attempts the replacement again, e.g. during the normal context
refresh() when this method will be called again.
Issue: SPR-8991
- Perform early check whether any ACI classes have been declared and
exit immediately if not, avoiding any other processing
- Polish method names in ContextLoaderTests
Issue: SPR-8991
The spring-aspects Maven pom had an incorrect compile-scoped dependence
on spring-test. In fact, spring-aspects only uses spring-test in its
unit tests. The pom has been updated accordingly, meaning that use
of spring-aspects in Maven-based applications will no longer require
spring-test on the classpath at runtime.
ivy.xml metadata did not need updating, as it was already correct.
This change is only necessary on the 3.1.x line; in 3.2.x (master) Maven
poms are generated automatically from Gradle dependency metadata, which
is also already correct.
Issue: SPR-9048
A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.
With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
Prior to this commit, @Configuration classes included via @Import (or
via automatic registration of nested configuration classes) would
always be registered with a generated bean name, regardless of whether
the user had specified a 'value' indicating a customized bean name, e.g.
@Configuration("myConfig")
public class AppConfig { ... }
Now this bean name is propagated as intended in all cases, meaning that
in the example above, the resulting bean definition of type AppConfig
will be named "myConfig" regardless how it was registered with the
container -- directly against the application context, via component
scanning, via @Import, or via automatic registration of nested
configuration classes.
Issue: SPR-9023
A number of users reported issues with comparing method identity vs
equivalence when discovering JavaBeans property methods in
ExtendedBeanInfo.
This commit updates the implementation to consistently use '.equals()'
instead of '=='.
Issue: SPR-8079, SPR-8347
This issue originates from a need in Spring Data JPA, wherein a custom
InstantiationAwareBeanPostProcessor may alter the predicted type of
FactoryBean objects, effectively preventing retrieval of those beans via
calls to #getBeansOfType(FactoryBean.class).
The reason for this "masking effect" is that prior to this change, the
implementation of AbstractBeanFactory#isFactoryBean considered only the
"predicted type" returned from #predictBeanType when evaluating
assignability to FactoryBean.class
The implementation of #isFactoryBean now ensures that not only the
predicted bean type is considered, but also the original bean
definition's beanClass (if one is available).
Issue: SPR-8954
