[
https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated RAVE-689:
---------------------------
Priority: Major (was: Blocker)
Affects Version/s: 0.12
Fix Version/s: (was: 0.12)
0.13
I've committed a workaround for now, so this no longer is a Blocker.
I'm therefore downgrading this to priority Major instead.
And as we intend to release 0.12 end of next week and I expect we'll need more
time to fix this properly, I'm bumping the Fix Version to 0.13 as well.
> 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.12
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 0.13
>
>
> 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
