[jira] [Updated] (RAVE-689) JpaConverter static converterMap can get 'corrupted' across multiple unit tests and causing tests to fail

["Raminderjeet Singh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raminderjeet Singh updated RAVE-689:
------------------------------------

    Fix Version/s:     (was: 0.14)
                   0.15
    
> 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
>    Affects Versions: 0.13
>            Reporter: Ate Douma
>             Fix For: 0.15
>
>
> 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