rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Created] (RAVE-689) JpaConverter static converterMap can get 'corrupted' across multiple unit tests and causing tests to fail
Date Fri, 22 Jun 2012 21:29:42 GMT
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


View raw message