You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2012/06/22 23:29:42 UTC
[jira] [Created] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
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
[jira] [Assigned] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Assigned] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Jasha Joachimsthal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jasha Joachimsthal reassigned RAVE-689:
---------------------------------------
Assignee: Ate Douma
> 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
> Assignee: 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
[jira] [Updated] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Jasha Joachimsthal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399952#comment-13399952 ]
Jasha Joachimsthal commented on RAVE-689:
-----------------------------------------
With your workaround I am not able to build the project in OSX, neither with Java6 nor with Java7.
all tests in org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest fail with the following messages:
createProxy(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
createProxy(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxyAdd(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxyAdd(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxySet(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxySet(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxyAddAll(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
proxyAddAll(org.apache.rave.portal.model.conversion.ConvertingListProxyFactoryTest): Conversion factory not set by the Spring context
> 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
[jira] [Comment Edited] (RAVE-689) JpaConverter static converterMap
can get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399629#comment-13399629 ]
Ate Douma edited comment on RAVE-689 at 6/22/12 10:05 PM:
----------------------------------------------------------
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.13 end of next week and I expect we'll need more time to fix this properly, I'm bumping the Fix Version to 0.14 as well.
was (Author: adouma):
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.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
[jira] [Commented] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399987#comment-13399987 ]
Matt Franklin commented on RAVE-689:
------------------------------------
Committed a slight variation on Ate's fix that resets the state of the converters from the autowired list of converters.
Use of the static member is obviously not optimal; but, in a spring context should be relatively. One thing we should do is to make the constructor package private to reduce the risk that it the widget map is replaced with a list that we don't want in a runtime environment.
> 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
> Assignee: 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
[jira] [Commented] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399989#comment-13399989 ]
Matt Franklin commented on RAVE-689:
------------------------------------
Ate & Jasha can you verify the fix works for you 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.13
> Reporter: Ate Douma
> Assignee: 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
[jira] [Updated] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated RAVE-689:
---------------------------
Affects Version/s: (was: 0.12)
0.13
Fix Version/s: (was: 0.13)
0.14
> 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
[jira] [Commented] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400056#comment-13400056 ]
Ate Douma commented on RAVE-689:
--------------------------------
Argh, stupid mistake.
While my fix did solve it when testing all tests, I forgot to test the modified ConvertingListProxyFactoryTest standalone...
When run alone it then failed because no JpaConverter instance would have been created upfront or before by other (Spring based) tests.
The fix from Matt does work as well of course, I even tried intended to apply that one myself before I figured out the more clean fix I committed (albeit with a bug of its own).
I prefer and will re-applying my earlier fix, and fixed, because it doesn't depends on Spring. Adding Spring usage just to prevent a problem feels like more 'dirty' to me ;)
> 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
> Assignee: 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
[jira] [Assigned] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ 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)
> 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
> 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
[jira] [Updated] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "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
[jira] [Commented] (RAVE-689) JpaConverter static converterMap can
get 'corrupted' across multiple unit tests and causing tests to fail
Posted by "Jasha Joachimsthal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399992#comment-13399992 ]
Jasha Joachimsthal commented on RAVE-689:
-----------------------------------------
I'm able to compile the project again, thanks
> 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
> Assignee: 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