Bugzilla – Full Text Bug Listing
| Summary: | Validation error during processing on parameterized generic OneToMany Entity relationship from MappedSuperclass | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Guy Pelletier <guy.pelletier> | ||||||||||
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P2 | CC: | eclipselink.orm-inbox, lloyd, tom.ware | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Guy Pelletier
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines Like to see the priority changed to P1 (or atleast P2) This is a show stopper and If I do not hear any word on it's priority/schedule I will move on to using a different product I did some debugging and this seems to happen only to generics that have type arguments which themselves are generics with type arguments or is an interface. The error seems to be in the method org.eclipse.persistence.internal.jpa.metadata.accessors.objects.MetadataAsmFactory.processDescription() which incorrectly parses <S:Lw/x/y/z/wfm/WFMState;U:Lw/x/y/z/core/security/User;V::Lw/x/y/z/wfm/WorkItemInterface;W:Lw/x/y/z/wfm/AbstractProcessActivityStatus<TS;TU;TV;TW;TY;TZ;>;Y:Lw/x/y/z/wfm/AbstractProcessPathStatus<TS;TU;TV;TW;TY;TZ;>;Z:Lw/x/y/z/wfm/AbstractProcessStatus<TS;TU;TV;TW;TY;TZ;>;>Ljava/lang/Object;Lw/x/y/z/core/persistence/PersistenceInterface;Ljava/io/Serializable;Ljava/lang/Comparable<Lw/x/y/z/wfm/AbstractProcessStatus<TS;TU;TV;TW;TY;TZ;>;>; to [S, :, w.x.y.z.wfm.WFMState, U, :, w.x.y.z.core.security.User, V, :, :, w.x.y.z.wfm.WorkItemInterface, W, :, w.x.y.z.wfm.AbstractProcessActivityStatus, T, S, T, U, T, V, T, W, T, Y, T, Z, Y, :, w.x.y.z.wfm.AbstractProcessPathStatus, T, S, T, U, T, V, T, W, T, Y, T, Z, Z, :, w.x.y.z.wfm.AbstractProcessStatus, T, S, T, U, T, V, T, W, T, Y, T, Z, java.lang.Object, w.x.y.z.core.persistence.PersistenceInterface, java.io.Serializable, java.lang.Comparable, w.x.y.z.wfm.AbstractProcessStatus, T, S, T, U, T, V, T, W, T, Y, T, Z] The method org.eclipse.persistence.internal.jpa.metadata.accessors.objects.MetadataAsmFactory.resolveGenericTypes() makes assumptions about what processDescription() returns Created attachment 192151 [details]
Changes made to get my code to work
In addition to correcting the parsing of generics - modified code to expect mapped super class fields to also check for Void in addition to String (default raw class)
Its been a month since I provided a patch. Can I expect any traction on this bug? Appologies for the delay, I'll take a look We currently have this bug targetted for our 2.3 release which will ship as part of the full Eclipse release at the beginning of July. What release are you hoping to see this fix appear in? What exception were you getting? Do your code changes make that exception go away? The code changes in the patch above do not solve the problem for my recreation.
public class Official <C extends Certification> {
...
@OneToMany
private List<C> certifications;
I get this excetion:
Caused by: Exception [EclipseLink-7214] (Eclipse Persistence Services - 2.2.1.qualifier): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The target entity of the relationship attribute [certifications] on the class [class org.eclipse.persistence.testing.models.jpa.inherited.Official] cannot be determined. When not using generics, ensure the target entity is defined on the relationship mapping.
at org.eclipse.persistence.exceptions.ValidationException.unableToDetermineTargetEntity(ValidationException.java:1913)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.CollectionAccessor.getReferenceClass(CollectionAccessor.java:461)
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.addAccessor(ClassAccessor.java:249)
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.addAccessorFields(ClassAccessor.java:387)
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.addAccessors(ClassAccessor.java:359)FATAL ERROR in native method: processing of -javaagent failed
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.preProcess(ClassAccessor.java:1093)
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.MappedSuperclassAccessor.preProcess(MappedSuperclassAccessor.java:627)
at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.preProcess(EntityAccessor.java:525)
at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage1(MetadataProject.java:1504)
at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:484)
at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:454)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1081)
... 18 more
Apparently I misunderstood the issue. Recreation should be more like this:
public class Official <C extends Certification> {
...
@OneToMany
private List<C> certifications;
public class OfficialSubclass<CertificationSubclass> extends Official [
The original recreation is invalid according to the spec and can be solved by specifying the target entity in the mapping annotations.
I can now recreate an issue related to this. The different that remains is that I do not need any of the MetadataAsmFactory changes to solve it. The one change to RelationshipAccessor is sufficient. Can you point me at a test case that requires the MetadataAsmFactory change? Created attachment 197138 [details]
Updated fix.
I am planning on checking the attached patch into 2.3.1 as soon as it opens. This patch excludes changes to MetadataFactory because I could not find a usecase the required them.
Checked into trunk (2.4) - 2.3.1 check-in to come when the stream opens Reviewed by Guy Pelletier Added test to org.eclipse.persistence.testing.tests.jpa.inheritance.EntityManagerJUnitTestCase Tested with JPA LRG Checked into 2.3.1 Still having problems. No value without the metadata fix. Switched to Hibernate due to poor support for generics and too much difficulty in getting issues resolved I am sorry we were unsuccessful at getting this working for you. I was unable to find a test case that required the change to the MetadataAsmFactory. I'd love to check in that change if there was a way for me to recreate a problem that required that change. At present time is limited - I will have to spend significant time moving stuff from my code into a test case. Can you commit to putting the fix in within a week of me providing a reproduceable test case. I am very interested in providing the necessary changes in our 2.3.1 release which is currently scheduled for early September. If a way to recreate this issue was available right now, I could make the commitment you are asking for, but, in the interest of full disclosure, my ability to provide a quick turnaround on the fix will depend a bit on my other commitments at the time that a recreation is availble. The attached patch has a set of mappings that recreate part of the problem, so perhaps a with a quick look at those mappings, you could suggest a change that i need to make to see the issue (as a way of avoiding additional work to create a test case) Created attachment 201232 [details]
Files to create issue as requested
I have stripped business logic from relevant classes and attached.
Reopening and investigating. Thanks for the recreation, it turns our what was missing is multiple levels of Generics.
Our initial test was simple:
public abstract class AbstractBus<I> extends FueledVehicle
I have updated to use the following:
public abstract class AbstractBus<H extends TireInfo<J>, I extends TireInfo<J>, J> extends FueledVehicle {
The key is that H extends something that also uses a generic and I is Mapped. Prior to your suggested fix, our processing of H would cause issues with determining the type of I.
Created attachment 201249 [details]
Patch that includes updated testing files and remainder of submitted patch
Checked in changes to test case described above and remainder of submitted patch. Tested with JPA LRG Reviewed by Tom Ware - reviewed user submitted patch. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |