Community
Participate
Working Groups
EclipseLink allows additional collection mapping types for EAGER relationships, such as TreeSet. EclipseLink validation should be tweaked to allow for other usage. For more info see James' comment here: http://www.eclipse.org/forums/index.php?t=rview&goto=748405#msg_748405
added bug 367122 to support validation for the correct collection types in generic JPA. This particular bug leads to invalid validation because there is no default target entity.
Created attachment 209217 [details] proposed patch against 3.0 maintenance
Created attachment 209228 [details] proposed patch against 3.0 maintenance new patch for maintenance that doesn't change API. I have applied the original patch to HEAD to fix the issue there
Approved pending successful test run.
test passed, fix checked in to maintenance
In Comment 1 I pointed to the wrong bug, the bug for validation the collection type in generic JPA is bug 368156
Verified in Build -3.3.2-20120119083703 Verified when you use TreeSet for the interface for an attribute in an entity for both a Generic project and EL project the target interface error does not appear. Also verified no errors appear if you use Collection, Set, List and Map interfaces. See the link to view test steps for verification. http://wiki.eclipse.org/Dali_3.0.2
I am reopening this bug because the fix for this will not work for a customer collection defined on the user's project classpath. It also causes a performance issue.
Given the following entity, the foos 1-m mapping has the incorrect validation error: 'Target entity for "foos" is not defined' @Entity public class Foo { @OneToMany private MyCollection<Foo> foos; } public class MyCollection implements Collection { ... }
Created attachment 214576 [details] proposed patch again HEAD I have made a provisional API change that I do not think is used by our adopters in the interface JavaPersistentAttribute.JpaContainerDefinition The method isAssignableFrom(String typeName) : boolean has been replaced with getTypeName() : String This was changed to fix this bug in an earlier milestone of 3.2 and now I am changing it back since the fix was incorrect, so there is no API change from the previous release. I have attached a patch against head to fix the original problem correctly and without the performance impact.
See comment 9 for more info on the changes and justification for this API change. Voting this through so we can get this change into this week's I-build.
fixed in M7
