Bugzilla – Full Text Bug Listing
| Summary: | JPA: Validation error during Id processing on parameterized generic OneToOne Entity relationship from MappedSuperclass | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Michael OBrien <michael.f.obrien> | ||||||
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P2 | CC: | andreas, douglas.clarke, eclipselink.orm-inbox, guy.pelletier, lloyd, michael.f.obrien, npquang_uns, odrotbohm, thanhlq421, thanhlq, tom.ware | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| URL: | http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04605.html | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 321694 | ||||||||
| Attachments: |
|
||||||||
|
Description
Michael OBrien
>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 |