In AnnotationUtils#findAnnotation(Method, Class), the search for a
method annotation fails if:
- the original method does not have the annotation
- an abstract superclass does not have an equivalent method declared
- an interface implemented by the superclass has the method and
the annotation -> this should be found, but is not!
This happens because the try-catch block in #findAnnotation is too wide:
cl.getDeclaredMethod() can throw NoSuchMethodException and skip the
'#searchOnInterfaces' call prematurely.
The try-catch block was made narrower to allow #searchOnInterfaces to
be called even if the abstract class does not have the method declared
at all.
Issue: SPR-9342
Overhauled the class-level JavaDoc in @Bean:
- added h3 headers for greater clarity and readability
- mentioned 'prototype' semantics for lite mode
Issue: SPR-9401
Prior to this change, Spring's MethodParameter#getParameterAnnotations
called java.lang.Method#getParameterAnnotations on every invocation.
The latter ends up contending for a monitor inside (Sun) JDK code. This
is problematic when dealing with the high number of @RequestMapping
invocations that can occur in a Spring MVC @Controller.
This commit eliminates this contention by caching values returned by
java.lang.Method#getParameterAnnotations in a static ConcurrentMap.
Note that only Method parameter annotations are cached, while
Constructor parameter annotations are not. This is because the
issue of primary concern is, as mentioned above, @RequestMapping
methods. By nature, constructors are called much more infrequently, and
in most cases in a single-threaded fashion.
Issue: SPR-9298
InjectionMetadata and LifecycleMetadata can end up having mostly empty
instance variables. In such cases memory usage can be improved a little
bit.
This patch addresses this in two ways:
- Creating a LinkedHashSet of the "right" size, the default capacity
is 16 but the exact capacity needed is known in advance.
- If the argument is empty then use Collections#emptySet which is a
constant so no additional memory is used. Since it's immutable there
is no need for the Collections#synchronizedSet wrapper.
Issue: SPR-9264
Prior to this change, AABPP#determineRequiredStatus never checked the
return value of ReflectionUtils#findMethod when searching for a
'#required' attribute. This call returns null for annotations such as
@Inject, @Value and @Resource, and subsequently causes a
NullPointerException to be thrown when ReflectionUtils#invokeMethod is
called. The NPE is caught immediately and #determineRequiredStatus
returns defaulting to true, but this this approach is inefficient. It
is also problematic for users who have set breakpoints on NPE -- they
end up debugging into Spring internals, which is a false positive.
This commit checks the return value of of ReflectionUtils#findMethod,
and in the case of null, eagerly returns true. There is no change to
external behavior, simply a more efficient and debugging-friendly
implementation.
Existing test cases already cover this change, given that it is purely
a refactoring.
Issue: SPR-9316
AbstractTransactionalAnnotatedConfigClassTests is now annotated with
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD) so
that side-effects between tests are avoided.
Re-enabled TransactionalAnnotatedConfigClassWithAtConfigurationTests
and TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests.
Also introduced a log4j FileAppender for tests that writes to
"build/spring-test.log".
Issue: SPR-9051
MappingJackson2JsonView and MappingJacksonJsonView now provide an
option that will set the Content-Length header of JSON responses.
Use of the option implies buffering of the response and it must be
enabled explicitly.
Issue: SPR-7866
This change makes it possible to provide a custom MessageCodesResolver
through the MVC Java config whether using @EnableWebMvc and extending
WebMVcConfigurerAdapter or sub-classing directly from
WebMvcConfigurationSupport.
Issue: SPR-9223
The claim: given an integration test class that is annotated with
@ContextConfiguration and declares a configuration class that is missing
an @Configuration annotation, if a transactional test method (i.e., one
annotated with @Transactional) changes the state of the database then
the
changes will not be rolled back as would be expected with the default
rollback semantics of the Spring TestContext Framework (TCF).
TransactionalAnnotatedConfigClassWithAtConfigurationTests is a concrete
implementation of AbstractTransactionalAnnotatedConfigClassTests that
uses
a true @Configuration class and thereby demonstrates the expected
behavior
of such transactional tests with automatic rollback.
TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests is a
concrete implementation of
AbstractTransactionalAnnotatedConfigClassTests
that does NOT use a true @Configuration class but rather a 'lite mode'
configuration class (see the Javadoc for @Bean for details).
Using such a 'lite mode' configuration class results in the following:
- Its @Bean methods act as factory methods instead of singleton beans.
- The dataSource() method is invoked multiple times instead of once.
- The test instance and the TCF operate on different data sources.
- The transaction managed (and rolled back) by the TCF is not the
transaction that the application code or test instance uses.
Ultimately, the use of a 'lite mode' configuration class gives the false
appearance that there is a bug in the TCF (in that the transaction is
not
rolled back); however, the transaction managed by the TCF is in fact
rolled back.
In conclusion, these tests demonstrate both the intended behavior of the
TCF and the fact that using 'lite mode' configuration classes can lead
to
confusing results (both in tests and production code).
Issue: SPR-9051
SPR-7680 added QueryTimeoutException to Spring's DataAccessException
hierarchy, but did not integrate it into the
SQLExceptionSubclassTranslator; it was added mainly to accomodate users
defining their own custom exception translators.
However, it does make sense to translate any SQLTimeoutException to this
new QueryTimeoutException type, and this commit makes that change. It
does represent a slight backward-incompatibility, given that
QueryTimeoutException extends TransientDataAccessException, whereas
SQLExceptionSubclassTranslator previously returned the more specific
TransientDataAccessResourceException for any SQLTimeoutException.
It is expected that this incompatibily will be very low-impact, i.e. not
affecting many (if any) users. In any case, a major release (Spring 3.2)
is the right time to introduce such a change, and the migration path is
straightforward: any users depending on catching
TransientDataAccessResourceException in the case of query timeouts
should update those catch blocks to expect QueryTimeoutException
instead. Care should also be taken to ensure correctness of existing
catch blocks expecting TransientDataAccessException, as these blocks
will now catch QueryTimeoutException as well.
Issue: SPR-9376, SPR-7680
SPR-7591 introduced a java.nio.charset.Charset field within
HttpStatusCodeException. The former is non-serializable, thus by
extension the latter also became non-serializable.
Because the Charset field is only used for outputting the charset name
in HttpStatusCodeException#getResponseBodyAsString, it is reasonable to
store the value returned by Charset#name() instead of the actual Charset
object itself.
This commit refactors HttpStatusCodeException's responseCharset field to
be of type String instead of Charset and adds tests to prove that
HttpStatusCodeException objects are once again serializable as expected.
Issue: SPR-9273, SPR-7591
The new property can be used to ignore specific exceptions that may
otherwise be matched by the "exceptionMappings" property or resolved
through the defaultErrorView.
Issue: SPR-5193
It was claimed that when a {@code @ContextConfiguration} test class
references a config class missing an {@code @Configuration} annotation,
@Bean dependencies are wired successfully but the bean lifecycle is not
applied (no init methods are invoked, for example).
AnnotatedConfigClassesWithoutAtConfigurationTests refutes this claim by
demonstrating that @Bean methods in non-@Configuration classes are
properly handled as "annotated factory bean methods" and that lifecycle
callbacks in fact apply to such factory beans.
Issue: SPR-9051
When @ResponseStatus has a reason and servletResponse.sendError() is
called, the response is committed and should no longer be written to.
After this change, the ServletInvocableHandlerMethod will mark the
response fully handled and will ignore any non-null return values.
Issue: SPR-9159
Before this fix the q-value of media types in the Accept header were
ignored when using the new RequestMappingHandlerAdapter in combination
with @ResponseBody and HttpMessageConverters.
Issue: SPR-9160
The Spring TestContext Framework (TCF) currently builds against TestNG
5.10. Thus in order to ensure that the TCF builds against the latest
release of TestNG without issues and in order to investigate the
possibility of integrating with newer TestNG features, we are upgrading to
version 6.5.2.
Note, however, that the Gradle build currently does not execute any TestNG
tests; this will be addressed in SPR-9398.
Issue: SPR-8221
Spring currently builds against JUnit 4.9; however, in order to ensure
that the Spring TestContext Framework builds and runs against JUnit 4.10
without issues and in order to investigate the possibility of integrating
with newer JUnit features, we are upgrading to JUnit 4.10.
Issue: SPR-9277
The MappingJacksonHttpMessageConverter now catches all IOException
types raised while reading JSON and translates them into
HttpMessageNotReadableException.
Issue: SPR-9238
Previously RequestMappingHandlerMapping detected @RequestMapping
methods through an initApplicationContext() hook. However, the
HandlerMapping may not have been fully set up with all its
dependencies at that point including settings like useSuffixPattern
and others.
This change moves the detection @RequestMapping methods to an
InitializingBean.afterPropertiesSet() hook.
Issue: SPR-9371
This was supported in DefaultAnnotationHandlerMapping but not in the
RequestMappingHandlerMapping. The specific scenario where this matters
is a controller decorated with a JDK proxy. In this scenario the
HandlerMapping looks at interfaces only to decide if the bean is a
controller. The @Controller annotation is better left (and required)
on the class.
Issue: SPR-9374
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
Two tests in MockServletContextTests were disabled with @Ignore with the
comment "fails to work under ant after move from .testsuite -> .test";
however, this no longer appears to apply with the Gradle build. Thus
these tests have been re-enabled.
The JavaDoc in OpMultiply contained special characters that caused
problems when building with Java 7 on Mac OS X. The section symbol has
been replaced with the word "Section". Also improved class-level and
method-level JavaDoc in general.
