rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raminderjeet Singh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (RAVE-689) JpaConverter static converterMap can get 'corrupted' across multiple unit tests and causing tests to fail
Date Tue, 31 Jul 2012 22:17:33 GMT

     [ 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

        

Mime
View raw message