Community
Participate
Working Groups
Created attachment 169375 [details] stack trace The following example triggers a StackOverflowError (attached): @Embeddable public class Foo { @ElementCollection private List<Foo> elementCollection; } At this point the workbench becomes pretty much unusable.
Also need to handle larger cycles like: @Embeddable public class Foo { @ElementCollection private List<Bar> bars; } @Embeddable public class Bar{ @ElementCollection private List<Foo> foos; }
Created attachment 169690 [details] proposed patch against head The attached patch fixes the first use case for element collection and embedded mappings in both java and orm. I also added JUnit tests for these cases.
Created attachment 169703 [details] proposed patch against head
I have entered bug 314150 for the second use case. We have decided that fixing this is too difficult and would involve too many changes this late in Helios. The fix for the first use case is simpler and we can at least handle that particular case that causes a StackOverflowError. Neither of these cases is all that likely, but the outcome if it does happen is bad.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Stack Overflow results in unstable workbench environment. * Is there a work-around? If so, why do you believe the work-around is insufficient? Avoid error case. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manually tested and unit tests have been added to detect this case. * Give a brief technical overview. Who has reviewed this fix? Change prevents stack overflow by checking for the condition where the target embeddable type and the owning type are the same. I have reviewed the fix. * What is the risk associated with this fix? Low risk.
checked in to head
Verified fixed in RC3
