Issue 1:
Mike Zupper opened SPR-794 and commented

Here is the scenerio:

MyAccountForm extends SimpleFormController

MyAccountValidator implements Validator

Within MyAccountForm I override the following method:

protected ModelAndView onSubmit(HttpServletRequest request,

HttpServletResponse response,

Object command,

BindException errors)

throws Exception

with proper validation and no errors, The framework should call the "onSubmit" method with the defined signature but it does not. If I override, the following method:

protected ModelAndView onSubmit(Object command)

throws Exception

it calls the "onSubmit" method properly.

I need to access the HTTP request to set session data.

I used my IDE's debugger to trace it down and I could not find any reason why that above onSubmit method does not work... Any Ideas????

Please see issue# #5420 for similar problem.

Thanks,

Mike Zupper (mzupper@boscovs.com)

Affects: 1.1.3, 1.1.4, 1.1.5

Attachments:

SimpleFormController.java (16.39 kB)

Issue Links:

#5420 After a successfull validation Spring does not call the onSubmit method with signature of (request, response,object, bindexception) ("duplicates")

Issue 2:
Kristian Rosenvold opened SPR-5863 and commented

Status Quo

Newer versions of JUnit support concurrent test execution; however, the Spring TestContext Framework is not designed for concurrency.

Proposed Solution

The enclosed fixes sharpen focus on concurrency (including making mutable state much more distinct from immutable state), increasing separation between data for each test method run and the class they are being run on.

The patch consists of a failing test (patch 1) and a fix (patch 2), including several new tests. If you choose to apply the patch with the failing test, you must revert this before applying the fix (failing test is contained in fix patch). The included failing test may not produce concurrency issues (fail) in all cases and on all hardware platforms. They have been known to fail consistently on 3 different machines, usually upon first run.

Details of the Patch

The patch contains minor changes to the ContextLoader interface. The most significant changes have been made to the TestContextManager and TestContext classes.

Additionally upon completing the functionality, I had multiple deadlocks in the JVM when running my real test suite. I solved this by using a Java 5 ReentrantReadWriteLock in the RequestAttributes.getSessionMutex() method. It really looks to me like the creation of this mutex should be moved to one of the loader filters, since it's always created as of this patch.

Additionally, the patch contains a MockContextLoader that transfers attributes between threads. I'd really like you guys to check that code out before accepting it; there may be other smarter ways of doing this. It's only a part of the test code-base, but once it's included it sets a standard.

Real-life Tests

The patch has been applied to a local version of Spring 3 that has been running stably with multi-core machines and multi-CPU servers too. We have been running a continuous build using parallel classes, methods, and a combination of both. This is a full-scale build that was adaptable to multi-threaded test execution. The application under test uses lots of web-scopes, etc.

Proposed Documentation

Parallel Test Execution

From version 3.0, Spring supports parallel test execution in the Spring TestContext Framework. Executing builds in parallel with JUnit is only supported in later versions of JUnit, and it is recommended to use at least JUnit 4.6 for this feature. Please also note that there's no guarantee your tests will run properly in parallel; a number of general concurrency issues have to be taken into account when executing tests in parallel. Your runner can usually let you choose between classes, methods, and a combination of both. Classes are usually the easiest to get working; "a combination of both" is the hardest. All three modes are supported.

Affects: 3.0 M3

Attachments:

1concurrencyFix2051.patch (77.48 kB)

2tests2051.patch (31.53 kB)

3428_SPR5863.patch (53.32 kB)

3dirtiesContext2051.patch (34.46 kB)

completeFix.patch (189.66 kB)

springFailingTest.patch (33.11 kB)

Issue Links:

#15263 Debug logging for DependencyInjectionTestExecutionListener breaks injection for parallel tests ("is duplicated by")

#18684 Problems running integration tests in parallel using SpringClassRule and SpringMethodRule ("is duplicated by")

#19549 using ParallelComputer to test spring test cases got error ("is duplicated by")

#17028 Improve thread safety in Spring JUnit integration ("is duplicated by")

#13582 Test execution issue: for "shared" test contexts in multithreading

#13499 @DirtiesContext does not destroy all cached singleton beans

#15166 Do not serialize ApplicationContext creation in the TestContext framework

#12343 Use soft or weak references for context caching in the TestContext framework

#12710 Limit size of context cache in the TestContext framework

Referenced from: commits e822e4c, 3dc6f11, fbfad86, 3e96cab, 2699504, a10a8e5, ec7aefa

42 votes, 40 watchers