The reference manual previously did not mention the applicability of
JSR-250 lifecycle annotations within the TestContext framework. The
lacking documentation here has lead to misunderstandings of the support
provided for @PostConstruct and @PreDestroy in test classes.
The testing chapter of the reference manual has therefore been updated
to explicitly define the limited support for these annotations.
Also introduced Jsr250LifecycleTests for empirical verification of the
expected behavior.
Issue: SPR-4868
Introduced AtBeanLiteModeScopeTests integration tests to verify proper
scoping of beans created in 'lite' mode.
Updated comments in TACCWithoutACTests to better reflect the runtime
behavior for 'lite' @Bean methods.
Issue: SPR-9401
Updated all Javadoc in the Spring TestContext Framework (TCF) to explain
and refer to 'annotated classes' instead of 'configuration classes'.
Specifically, @ContextConfiguration now explicitly defines what is meant
by 'annotated classes', and various other classes now refer to this
definition. Otherwise, the term 'configuration class' has simply been
replaced with 'annotated class'.
Also deleted cross references to deprecated JUnit 3.8 classes and
formatted Javadoc in general for greater readability.
Issue: SPR-9401
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
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
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
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.
Before this change there were numerous javadoc warnings being reported
while building Spring framework API.
This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.
Issue: SPR-9113
Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.
Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.
Issue: SPR-9097
* 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
...
Each of these tests began failing during the Gradle build porting
process. None seem severe, many are likely due to classpath issues.
In the case of TestNG support, this needs to be added to the Gradle
build in order to execute these tests. See SPR-8116.txt
This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.
Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example
$ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history up until the renaming event, where
$ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history for all changes to the file, before and after the
renaming.
See http://chrisbeams.com/git-diff-across-renamed-directories
Sam Brannen
Stevo Slavic
Chris Beams