GitHub-Spring/spring-framework - spring-framework - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Sam Brannen	500a4dd995	Fix tx annotated tests so that they pass in the build 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	14 years ago
Sam Brannen	2017b24867	Disable tx annotated tests until working within the build Issue: SPR-9051	14 years ago
Sam Brannen	1cec0f9c65	Investigate claims made in SPR-9051 regarding transactional tests 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	14 years ago
Sam Brannen	78c6d70f0b	Refute claims made in 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	14 years ago
Sam Brannen	0b17dd2242	Fix misleading JavaDoc in ProfileAnnotationConfigTestSuite	14 years ago
Sam Brannen	80af842662	Re-enable ignored tests in MockServletContextTests 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.	14 years ago
Chris Beams	ddf8eaf38a	Mark remaining @Ignored tests with 'TODO SPR-8116' 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	14 years ago
Chris Beams	02a4473c62	Rename modules {org.springframework.=>spring-} 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	14 years ago