Community
Participate
Working Groups
>Issue from eclipselink user on the forum below http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04605.html >Unable to validate the following model that contains a OneToOne entity relationship from a MappedSuperclass to a parameterized generic entity I took the liberty of completing your model by creating an Entity MyField class and either an Entity or MappedSuperclass MyGenericType I get the same exception as yourself, except for the fact that the validation error occurs on the defining superclass instead of the MyClass subclass in your case. >The fact that F extends a entity MyField should allow this to pass. I suspect that this issue requires a but at least for defining invalid configurations. @Entity public class MyClass extends MyGeneric<MyGenericType>{ @Id private Long id; } @MappedSuperclass public abstract class MyGeneric <F extends MyField > implements MyInterface { @ManyToOne private F myfield; } public interface MyInterface {} @MappedSuperclass public abstract class MyGenericType extends MyField {} @Entity public class MyField { @Id private Long id; } Exception Description: [class org.eclipse.persistence.example.dataparallel.model.MyGeneric] uses a non-entity [class java.lang.String] as target entity in the relationship attribute [field myfield]. at org.eclipse.persistence.exceptions.ValidationException.nonEntityTargetInRelationship(ValidationException.java:1327) >note: MyClass must have an @Id at its level or higher in its mappedSuperclass heirarchy or we get the following Exception Description: Entity class [class org.eclipse.persistence.example.dataparallel.model.MyClass] has no primary key specified. It should define either an @Id, @EmbeddedId or an @IdClass. If you have defined PK using any of these annotations then make sure that you do not have mixed access-type (both fields and properties annotated) in your entity class hierarchy. at org.eclipse.persistence.exceptions.ValidationException.noPrimaryKeyAnnotationsFound(ValidationException.java:1350) >The error is actually happening before the 1:1 processing - when we compute the pk field name in getReferenceDescriptor() String defaultPKFieldName = getReferenceDescriptor().getPrimaryKeyFieldName(); >The reference descriptor on the MyClass entity is String - which looks wrong to me. this OneToOneAccessor (id=31) m_referenceClass MetadataClass (id=87) m_type "java.lang.String" (id=109) >stacktrace org.eclipse.persistence.example.dataparallel.GridClient at localhost:57261 Thread [Main Thread] (Suspended (breakpoint at line 416 in RelationshipAccessor)) ManyToOneAccessor(RelationshipAccessor).getReferenceDescriptor() line: 416 ManyToOneAccessor(ObjectAccessor).processOneToOneForeignKeyRelationship(OneToOneMapping) line: 609 ManyToOneAccessor(ObjectAccessor).processOwningMappingKeys(OneToOneMapping) line: 678 ManyToOneAccessor.process() line: 107 ManyToOneAccessor(RelationshipAccessor).processRelationship() line: 625 MetadataProject.processRelationshipAccessors() line: 1137 MetadataProject.processStage3() line: 1420 MetadataProcessor.processORMMetadata() line: 464 PersistenceUnitProcessor.processORMetadata(MetadataProcessor, boolean) line: 427 EntityManagerSetupImpl.predeploy(PersistenceUnitInfo, Map) line: 951 JavaSECMPInitializer(JPAInitializer).callPredeploy(SEPersistenceUnitInfo, Map, PersistenceInitializationHelper, String, String) line: 88 >Stacktrace OneToOne org.eclipse.persistence.example.dataparallel.GridClient at localhost:57274 Thread [Main Thread] (Suspended (breakpoint at line 416 in RelationshipAccessor)) OneToOneAccessor(RelationshipAccessor).getReferenceDescriptor() line: 416 OneToOneAccessor(ObjectAccessor).processOneToOneForeignKeyRelationship(OneToOneMapping) line: 609 OneToOneAccessor(ObjectAccessor).processOwningMappingKeys(OneToOneMapping) line: 678 OneToOneAccessor.process() line: 175 OneToOneAccessor(RelationshipAccessor).processRelationship() line: 625 MetadataProject.processRelationshipAccessors() line: 1137 MetadataProject.processStage3() line: 1420 MetadataProcessor.processORMMetadata() line: 464 PersistenceUnitProcessor.processORMetadata(MetadataProcessor, boolean) line: 427 EntityManagerSetupImpl.predeploy(PersistenceUnitInfo, Map) line: 951 JavaSECMPInitializer(JPAInitializer).callPredeploy(SEPersistenceUnitInfo, Map, PersistenceInitializationHelper, String, String) line: 88 >Hopefully this is not a case of an unitialized field during mappedSuperclass processing of the pseudo RelationalDescriptor we added for the JPA 2.0 metamodel - if so it will become design issue 103 after http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_102:_20100421:_Fully_initialize_MappedSuperclass_Descriptors_and_Refactor_existing_workarounds
>The validation error will occur wherever the @Id is defined - here I moved it up to the @MappedSuperclass from the implementing @Entity Exception Description: [class org.eclipse.persistence.example.dataparallel.model.MyClass] uses a non-entity [class java.lang.String] as target entity in the relationship attribute [field myfield]. at org.eclipse.persistence.exceptions.ValidationException.nonEntityTargetInRelationship(ValidationException.java:1327) - which replicates your exception exactly
>workaround: set the targetEntity on the @ManyToOne or @OneToOne unidirectional mapping Use the following mapping annotation where we let Metadata processing know what the target entity is. @ManyToOne(targetEntity=MyField.class) private F myfield; >Still, the validation exception needs to be modified to report the actual problem not the secondary exception - we don't have enough info in the mapping - not that the @Id processing is failing on default String handling
For an example see use cases 1 to 8 for design issue 63 (Map Support) for JPA 2.0 http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_63:_20090824:_Add_Map_support_for_.40MapKey_to_MapAttribute With this annotation addition, you will no longer get a ValidationException as seen in the log excerpt below. LOGS: [EL Config]: 2010-05-08 10:02:55.922--ServerSession(37462178)--Thread(Thread[Main Thread,5,main])--The alias name for the entity class [class org.eclipse.persistence.example.dataparallel.model.MyField] is being defaulted to: MyField. [EL Config]: 2010-05-08 10:02:55.962--ServerSession(37462178)--Thread(Thread[Main Thread,5,main])--The alias name for the entity class [class org.eclipse.persistence.example.dataparallel.model.MyClass] is being defaulted to: MyClass. [EL Config]: 2010-05-08 10:02:56.022--ServerSession(37462178)--Thread(Thread[Main Thread,5,main])--The foreign key column name for the mapping element [field myfield] is being defaulted to: MYFIELD_PU_ID. [EL Finest]: 2010-05-08 10:02:56.022--ServerSession(37462178)--Thread(Thread[Main Thread,5,main])--End predeploying Persistence Unit dao.create.tables.derby; session file:/C:/wse/wls10330/org.eclipse.persistence.example.dataparallel.client/bin/_dao.create.tables.derby; state Predeployed; factoryCount 0
Created attachment 172157 [details] Testcase showing bug Hi out there, this seems to be broken for @OneToOne relationships since 1.2.0 already. For 1.1.x and 1.0.x it works fine. Attached you'll find a sample Maven project: mvn clean test -> runs fine as it uses 1.0.2 mvn clean test -Pel11 -> runs fine (uses 1.1.3) mvn clean test -Pel12 -> test fails with the exception described above mvn clean test -Pel20 -> same fail Regards, Ollie
Is there a chance to raise the priority of this bug a little? We have an open source project running, we actually wanted to release a 2.0 version of that builds on top of JPA 2.0 and use a @OneToOne relationship in one of our domain helper classes. We already have been waiting for all major JPA 2.0 implementors to provide a 2.0 ready version but it seems we won't get EclipseLink working if this one doesn't get fixed. I did some debugging on this and it seems that the accessors correctly determine the concrete types but in case of the relationship the substitues for the generic type at the field does not get replaced by the concrete type. Regards, Ollie
Hi, Please help to plan this bug in a nearest future version because we need some futures in V2.x.x but we cannot upgrade our application because of this bug. Thanks in advanced, Thanh Le
>raising priority and targetting for 2.2 release
>Thanh, Ollie, is the targetEntity workaround in comment 3 sufficient until this issue is fixed
(In reply to comment #8) > >Thanh, Ollie, is the targetEntity workaround in comment 3 sufficient until this issue is fixed Hi Michael, thanks for raising the priority for this although it will probably take a while until 2.2 is being released now that 2.1 is just scheduled for today. :) Anyway, the workaround won't make it for us as we provide the base class as library class to other projects that in turn inherit from it to hook in their own class there: Here's the class in case you want to take a look: http://redmine.synyx.org/projects/hades/repository/entry/trunk/hades/src/main/java/org/synyx/hades/domain/auditing/AbstractAuditable.java Regards, Ollie
>Understood - Parameterized Generics is an issue here. Just a note that as soon as this is would be fixed and the SVN Rev# is released you can pick up the nightly milestone and not wait for the official 2.2 release. >depending on weekly prioritization at the eclipselink dev meeting at 1100EDT the fix could go into 2.1.1 or a possible 2.1.2, you are welcome to attend the meeting. http://wiki.eclipse.org/EclipseLink/DevMeetings >also, raising this issue and on the users list by replying to the original post by [Frank] will reach a wider audience and draw attention to the bug. http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04605.html http://old.nabble.com/EclipseLink-f26430.html >another way to raise the priority is for non-committer (users) to vote on the bug - it currently has only 1 vote but has 3 interested users - this will push it up the priority queue quickly
Hi Michael, I have the same case as Ollie, we're building a generic library for re-using from many sub projects so the proposed work-around doesn't fix our problem. From the wiki (http://wiki.eclipse.org/EclipseLink/Development/2.2), I saw the plan of the v2.2 release is until December 8th, 2010 which is not possible for us to wait... So It would be great if we have some advices for a hot fix or patch... Thanks in advanced, Thanh Le
Hello there, I met the same problem ValidationException ... Our project is too rush to wait for the next release. Can this bug have a higher priority to be fixed in some next nightly build? Thanks, Quang
Comment to receive
Created attachment 176352 [details] Proposed changes
Changes have been submitted. Reviewed by: Tom Ware, Micheal O'Brien, James Sutherland Model change to inherited model to expose the validation exception. With fix in place, exception does not occur and existing JPA FullRegressionTest and extended test suite passed successfully.
(In reply to comment #15) > Changes have been submitted. > > Reviewed by: Tom Ware, Micheal O'Brien, James Sutherland > > Model change to inherited model to expose the validation exception. With fix in > place, exception does not occur and existing JPA FullRegressionTest and > extended test suite passed successfully. Hi, thanks for fixing this so quickly. Is there a chance to test a nightly build ore something? When is 2.2.0 about to be released? Regards, Ollie
Nightly builds can be picked up here: http://www.eclipse.org/eclipselink/downloads/nightly.php Cheers, Guy
(In reply to comment #17) > Nightly builds can be picked up here: > > http://www.eclipse.org/eclipselink/downloads/nightly.php > > Cheers, > Guy This seems to work now :). Unfortunately my test suit now stumbles above something more core which seems to be broken: https://bugs.eclipse.org/bugs/show_bug.cgi?id=322579
Hi, will this make it in 2.2.0 only or rather be shipped with 2.1.2? When will those version be released? Although there is a release plan for 2.2 at [1], I couldn't find anything beyond 2.1 at [2], [3], [4], which are listed more publically on the project website [5]. Regards, Ollie [1] - http://wiki.eclipse.org/EclipseLink/Development/2.2 [2] - http://www.eclipse.org/projects/project-plan.php?projectid=rt.eclipselink [3] - http://www.eclipse.org/projects/timeline/index.php?projectid=rt.eclipselink [4] - http://wiki.eclipse.org/EclipseLink/Release [5] - http://www.eclipse.org/eclipselink/
This does not work if you add additional parameters. In example below the code treats F2 as type MyGenericType instead of MFType2 @Entity public class MyClass extends MyGeneric<MyGenericType, MFType2>{ @Id private Long id; } @MappedSuperclass public abstract class MyGeneric <F extends MyField, F2 extends MyField2 > implements MyInterface { @ManyToOne private F myfield; private F2 myField2; }
Quickly looking at your model, curious if you still have the issue if you use a single character as the type. Rather than "F2", use "G" instead, that is: public abstract class MyGeneric <F extends MyField, G extends MyField2 >
Note type parameters naming can only be single characters as outlined here: http://download.oracle.com/javase/tutorial/java/generics/gentypes.html Lloyd confirmed that his model worked when he changed F2 to G. However he did hit another validation exception when using an one to many mapping. To all intents and purposes, this bug has been correct (as the title refers to one to one) and since 2.2 is locked down, bug 336133 has been opened to look at the validation exception for x to many mappings.
(In reply to comment #22) > Note type parameters naming can only be single characters as outlined here: > > http://download.oracle.com/javase/tutorial/java/generics/gentypes.html I'd consider a "naming convention" something different from a "can only be". In fact, there's nothing preventing you from doing it, as it's a type identifier, nothing less. Do you think it's worth opening a ticket to support generic types with multiple characters as well or shall we track it at the new ticket you mentioned?
I would log a new bug/enhancement for that. If we don't support it we could certainly handle it better (atleast give a clearer exception)
(In reply to comment #24) > I would log a new bug/enhancement for that. If we don't support it we could > certainly handle it better (atleast give a clearer exception) Opened a ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=336140
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
