Prior to changes in commit 57851de88e,
AbstractResource#getFilename threw IllegalStateException unless
overridden by a subclass. Following that change, this method now throws
null instead, but ResourceTests#testAbstractResourceExceptions had not
been updated to reflect, resulting in a false negative failure. This has
now been fixed.
Issue: SPR-9043
Eclipse allows autoboxing on type inference; Sun javac does not. This
means that variables assigned from calls to
AnnotationAttributes#getNumber should consistently use object wrappers
as opposed to number primitives. There was only one such instance
anyway, and has now been updated accordingly.
* 3.1.x: (61 commits)
Compensate for changes in JDK 7 Introspector
Avoid 'type mismatch' errors in ExtendedBeanInfo
Polish ExtendedBeanInfo and tests
Infer AnnotationAttributes method return types
Minor fix in MVC reference doc chapter
Hibernate 4.1 etc
TypeDescriptor equals implementation accepts annotations in any order
"setBasenames" uses varargs now (for programmatic setup; SPR-9106)
@ActiveProfiles mechanism works with @ImportResource as well (SPR-8992
polishing
clarified Resource's "getFilename" method to consistently return null
substituteNamedParameters detects and unwraps SqlParameterValue object
Replace spaces with tabs
Consider security in ClassUtils#getMostSpecificMethod
Adding null check for username being null.
Improvements for registering custom SQL exception translators in app c
SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera
Minor polish in WebMvcConfigurationSupport
Detect overridden boolean getters in ExtendedBeanInfo
Polish ExtendedBeanInfoTests
...
Prior to JDK 7, java.beans.Introspector registered indexed write methods
irrespective of return type, for example either of the following methods
were legal
void setFoo(int i, Foo foo)
Object setFoo(int i, Foo foo)
This was considered a bug and disallowed starting with JDK 7, such that
only the former signature is a candidate.
Supporting non-void returning setter methods is exactly what
ExtendedBeanInfo was designed to do, and prior to this commit, the
implementation of ExtendedBeanInfo assumed this (somewhat surprising)
behavior from the underlying Introspector, and because it worked out of
the box, took no extra steps to recognize and register these methods.
For this reason, non-void returning indexed write methods were not
registered under JDK 7+, causing test failures in ExtendedBeanInfoTests.
Now the implementation is careful to detect these methods without any
assumption about Introspector behavior, such that they are registered in
exactly the same fashion across JDK versions.
Issue: SPR-9014
Prior to this commit, ExtendedBeanInfo would add non-indexed write
methods without consideration for the presence of indexed read/write
methods, which is invalid per the JavaBeans spec and per the behavior
of java.beans.Introspector. That is, a method with the signature
void setFoo(Foo foo)
Should never be registered as a write method if the following method
signature is also present in the class
void setFoo(int i, Foo foo)
In most cases, this oversight caused no problems, but in certain
situations where a bean actually contains such a mismatch of methods,
"type mismatch" errors were thrown when ExtendedBeanInfo attempted the
illegal addition against the underlying property descriptor.
The implementation is now more careful about checking the parameter type
of write methods -- if the property descriptor in question is an
IndexedPropertyDescriptor, i.e. has an indexed write method, then any
non-indexed write method candidate must have a single *array* parameter,
which conforms to the spec and to Introspector behavior.
Issue: SPR-8937
- Drop 'expectedType' parameter from #getClass and #getEnum methods and
rely on compiler inference based on type of assigned variable, e.g.
public @interface Example {
Color color();
Class<? extends UserType> userType();
int order() default 0;
}
AnnotationAttributes example =
AnnotationUtils.getAnnotationAttributes(Example.class, true, true);
Color color = example.getEnum("color");
Class<? extends UserType> userType = example.getClass("userType");
or in cases where there is no variable assignment (and thus no
inference possible), use explicit generic type, e.g.
bean.setColor(example.<Color>getEnum("color"));
- Rename #get{Int=>Number} and update return type from int to
<N extends Number>, allowing invocations such as:
int order = example.getNumber("order");
These changes reduce the overall number of methods exposed by
AnnotationAttributes, while at the same time providing comprehensive
access to all possible annotation attribute types -- that is, instead of
requiring explicit #getInt, #getFloat, #getDouble methods, the
single #getNumber method is capabable of handling them all, and without
any casting required. And the obvious additional benefit is more concise
invocation as no redundant 'expectedType' parameters are required.
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
The username is usually not null, but it could be for some embedded databases.
Always setting generatedKeysColumnNameArraySupported to false when getGeneratedKeysSupported is false, since it can't be supported without having generated keys supported. This change only affects logging messages.
Issue: SPR-9006
Adding a static CustomSQLExceptionTranslatorRegistry and a CustomSQLExceptionTranslatorRegistrar that can be used to register custom SQLExceptionTranslator implementations for specific databases from any application context.
This can be used in application contexts like this:
<bean class="org.springframework.jdbc.support.CustomSQLExceptionTranslatorRegistrar">
<property name="sqlExceptionTranslators">
<map>
<entry key="H2">
<bean class="com.yourcompany.data.CustomSqlExceptionTranslator"/>
</entry>
</map>
</property>
</bean>
Issue: SPR-7675
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
The build script should work against http anyway; use of https here was
an oversight. Changing it now is in response to the following build
failure experienced by a user on his initial attempt to build from
source (with --info output):
09:02:09.437 [ERROR] [org.gradle.BuildExceptionReporter] Caused
by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
...
Cause: Could not GET
https://repo.springsource.org/plugins-snapshot/org/springframework/
build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml
The actual cause is unknown at this time, but worth noting that upon
switching the url to http, the following log message was issued:
Forcing close on abandoned resource: Http GET Resource:
http://repo.springsource.org/plugins-snapshot/org/springframework/
build/gradle/docbook-reference-plugin/0.1.2-SNAPSHOT/maven-metadata.xml
