Ate Douma created RAVE-689:
------------------------------
Summary: JpaConverter static converterMap can get 'corrupted'
across multiple unit tests and causing tests to fail
Key: RAVE-689
URL: https://issues.apache.org/jira/browse/RAVE-689
Project: Rave
Issue Type: Bug
Reporter: Ate Douma
Assignee: Ate Douma
Priority: Blocker
Fix For: 0.12
For *me* rave-jpa unit-tests in the model_interfaces branch have been failing
since some time, but seemingly not for many/most others.
The error is always an IllegalArgumentEception thrown by JpaConverter convert
method: No ModelConverter found for type <class>.
After having discussed this with Matt and debugged this myself, it very much
looked like this was an environmental issue. More specifically: it looked like
this was caused by a different ordering of files on my filesystem...
And this I could confirm after some test tweaking: by configuring the maven
surefire plugin with <runOrder>filesystem</runOrder> it will fail, but with
<runOrder>alphabetical</runOrder> it will succeed!
But of course this isn't the real cause of the problem.
The problem is caused by JpaConverter being @autowired by Spring, and because
Spring internally caches its earlier configured contexts...
Meaning: for the same Spring context (configuration), it will only once
initialize/autowire singleton beans. Even across test classes!
This works for most without notice, as the JpaConverter stores its autowired
convertermap as *static* member. So, as long as nobody changes this map, every
subsequent test which also needs this will keep working as expected. That is:
accidentally.
So why does this break on my machine? Because there is one (enabled) test
class, ConvertingListProxyFactoryTest, which *does* change the JpaConverter
internal static converterMap. Filling and overriding it with EasyMock converter
instances.
And, as Spring is unaware of this, any test executed *after* the
ConvertingListProxyFactoryTest which still expects the JpaConverter map to be
valid, will fail.
And it so happens that on *my* machine this ConvertingListProxyFactoryTest
somehow is executed in a different order than on most other systems.
Anyway, the real morale of this is:
Never trust and rely on statics members within environments where the
context/dependency injection might need to be reloaded, e.g. in non-forked
multiple unit-test execution, or (more important) refreshable web application
contexts.
As the current JpaConverter implementation and usage is quite invasive,
properly fixing/refactoring this is a bit out-of-scope for the goal of this
model_interfaces branch. But should be addressed once the branch has been
merged back into trunk.
For the time being I will instead provide a simple fix for
ConvertingListProxyFactoryTest to prevent the 'corruption' of the static
converterMap after the test.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
