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

        

Mime
View raw message