-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InvocationTargetException testing partial entities #35
Comments
Are there any chances these tests are running in parallel? |
As we've subsequently discussed in email, no it's just a single test method. (Also, this is running within Eclipse—is there a way to set JUnit concurrency within Eclipse?) If you end up adding the locking mechanism you talked about elsewhere, I'll see if that has any effect, though presumably that would only help if parallel testing was the problem, and in this case it can't be, right? |
I've reproduced it! I'm looking for a solution. I think the clue is in this log statement:
It appears only if the test throws the mentioned exception. |
Great news Henrique. Let me know if there's anything I can do to help. |
…che method from the wrong EOModel The `ERXModelGroup` class may create duplicate models in some cases. They are not added to the model group, but their presence may cause problems. The root cause of this problem is related to the duplication of `NSBundle` references while loading `EOModel`s. This fix uses a `NSMutableSet` instead of a `NSMutableArray` to hold the references to all loaded bundles. It avoids the presence of duplicate bundles and therefore the presence of duplicate model references. One can find more information about the issue at the above link. hprange/wounit#35
I've found the root cause of the problem. Unfortunately, its a bug in Project Wonder. I'm not sure I can do something on WOUnit to workaround this problem. I've added a few log messages to
Pay attention to lines 5 and 8. At line 5, the model group refuses to load the model I have no idea why the prototype is loaded from the wrong model. In spite of that fact, I know how to fix the Wonder code to avoid the creation of duplicate models. I've created the pull request wocommunity/wonder#551 as an attempt to solve this problem. Would you mind to try it? |
I will test it out, yes. Give me a couple of days. |
The |
I should have closed this back in March. The fix to |
…che method from the wrong EOModel The `ERXModelGroup` class may create duplicate models in some cases. They are not added to the model group, but their presence may cause problems. The root cause of this problem is related to the duplication of `NSBundle` references while loading `EOModel`s. This fix uses a `NSMutableSet` instead of a `NSMutableArray` to hold the references to all loaded bundles. It avoids the presence of duplicate bundles and therefore the presence of duplicate model references. One can find more information about the issue at the above link. hprange/wounit#35
This is similar to the issue I reported in #32 (in that it occurs with the exact same test I described there), but it's a different looking stack trace now.
I may have contributed to some confusion here, in that I pulled the test described in #32 from my test suite altogether, and then described a different partials-related problem (whereby attributes added by the augmented entities weren't being recognised as merged into the base entity) which was completely fixed in the recent 1.2.3 release.
What I'm seeing now is an
InvocationTargetException
trying to test the base class at the framework level. I'll reproduce here the code from #32, as it's the same:Worse, the problem is non-deterministic: sometimes this test will pass, sometimes it will fail. When it fails, this is the current stack trace:
Note that that is different to the stack trace in #32.
So, to re-iterate, 1.2.3 completely solves the initialisation-related issue with merging of properties down to the base class. But the problem of testing just the base classes seems to persist.
Henrique, I'm going to send you my framework and its tests out of band in the hope you can pinpoint the problem quickly.
The text was updated successfully, but these errors were encountered: