
| Key: |
SPR-2612
|
| Type: |
Improvement
|
| Status: |
Open
|
| Priority: |
Trivial
|
| Assignee: |
Unassigned
|
| Reporter: |
Alin Dreghiciu
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
Spring 2.0-RC3/4, EasyMock 1.2_Java1.3, EasyMockClassExtension 1.2, asm 1.5.3
|
|
| Virtual Machine: |
Sun JVM
- 1.4.2
|
AbstractMessageListenerContainer class has only two publc methods declared as final: isActive() and isRunning(). In a runtime usage I can not find now any use care where you would like to override this so, there is nothing wrong about. The hard part starts when you would like to start doing unit tests that checks that the classes that uses DefaultMessageListenerContainer (or the 102) have the correct behavior.
Concrete, by mocking the DefaultMessageListenerContainer102 with EasyMock class extension (since there is no interface) the two methods cannot be mocked so, the normal behaviour is executed. Starting with RC3 and the new syncronization implementation the syncronized(this.lifecycleMonitor) will fail the tests by throwing a NullPointerException. This happens due to the fact that easymock class extension will not call any constructor/initializing code so, the private final lifecycleMonitor will not be initialized to a new Object().
In order to avoid this kind of situations (Spring is promoting testability) can there be an interface exposing the public interface of the MessageListenerContainer or at least remove the final modifier in order to have a proper mocking.
|
|
Description
|
AbstractMessageListenerContainer class has only two publc methods declared as final: isActive() and isRunning(). In a runtime usage I can not find now any use care where you would like to override this so, there is nothing wrong about. The hard part starts when you would like to start doing unit tests that checks that the classes that uses DefaultMessageListenerContainer (or the 102) have the correct behavior.
Concrete, by mocking the DefaultMessageListenerContainer102 with EasyMock class extension (since there is no interface) the two methods cannot be mocked so, the normal behaviour is executed. Starting with RC3 and the new syncronization implementation the syncronized(this.lifecycleMonitor) will fail the tests by throwing a NullPointerException. This happens due to the fact that easymock class extension will not call any constructor/initializing code so, the private final lifecycleMonitor will not be initialized to a new Object().
In order to avoid this kind of situations (Spring is promoting testability) can there be an interface exposing the public interface of the MessageListenerContainer or at least remove the final modifier in order to have a proper mocking.
|
Show » |
Sort Order:
|
Please also note that this will happen only in a Sun JVM above 1.3 since that's the place where the easymock class implementation extension succeeded to avoid calling the object construction.
Also by using EasyMock class extension 1.1. this will nto happend due a different implementation of object instantiation that will call the object construction.