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] [Assigned] (RAVE-689) JpaConverter static converterMap can get 'corrupted' across multiple unit tests and causing tests to fail
Date Sat, 23 Jun 2012 21:09:42 GMT

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

Ate Douma reassigned RAVE-689:

    Assignee:     (was: Ate Douma)

With the fix I've just committed the workaround should be 'stable'. 
> 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.14
> 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