Community
Participate
Working Groups
Scenario: P is marked as @Entity @Inheritance C1 extends P and is marked as @Entity C2 extends P and is marked as @Entity and has @ManyToOne referencing P (named "parent") Using this we can build trees, as C2 has a tree uplink that can point to either C1 or C2 thanks to the common ancestor P: C1 ! +- C2 ("parent" points to C1 instance) ! +- C2 ("parent" points to C2 instance) ! +- C2 ! ... Accessing a collection that contains C2 instances failes with the following message: "Trying to set value [C1] for instance variable [parent] of type [P] in the object. The specified object is not an instance of the class or interface declaring the underlying field, or an unwrapping conversion has failed." Well, as C1 is a descendent of P, the above message is wrong! We are totally stuck now as we may not change the table schema, but have to deliver a JPA based software which is able to reflect this flexible type of trees. Is there a workaround or patch we can apply to convince EclipseLink that a C1 instance is definitively a P due to the inheritance?
No comments so far... anything you like me to do meanwhile?
I recommend sending something to eclipselink-users@eclipse.org or posting on the EclipseLink forums for a quicker response. http://www.eclipse.org/forums/index.php/f/111/
(In reply to comment #2) > I recommend sending something to eclipselink-users@eclipse.org or posting on > the EclipseLink forums for a quicker response. > > http://www.eclipse.org/forums/index.php/f/111/ Started discussion in EclipseLink forum: http://www.eclipse.org/forums/index.php/m/901019/#msg_901019
Created attachment 219861 [details] Maven based test case. Run "mvn test" to see the bug. Check source code comments to understand how it works. I have attached a maven based test case that demonstrates the bug. Simply unpack the zip archive then cd into it and run "mvn test". After few seconds you will see the bug (the message appears that C1 type cannot be set into P typed field). Please check the source code comments to understand the constraints under which the bug happens and how the test works like.
Anything you like us to check? Any ideas?
From the forum post: Your issue seems to be class loader related. JUnit does some odd class loader things depending on how you run it, you seem to be encounter this, but sharing your emf from previous tests. You need to set JUnit to run the tests with the same class loader, or not share anything between them. Did you find out anything based on this?
Deferring based on proximity of 2.4.1 release.
(In reply to comment #6) > From the forum post: > > Your issue seems to be class loader related. > JUnit does some odd class loader things depending on how you run it, you > seem to be encounter this, but sharing your emf from previous tests. > You need to set JUnit to run the tests with the same class loader, or not > share anything between them. > > Did you find out anything based on this? (1) I did not find anything in the JPA spec that everything must happen in the same classloader or that EMFs created by different classloaders must not be shared amongst MFs created from different classloaders (also everything else is working well!). Maybe this should get added in the spec? Maybe it is part of the spec and I am simply blind. (2) I do not know how I (as a user) should be able to find out what crazy magic the geniuses at junit.org are doing internally?
I confirm that everyting works well in JUnit as soon as the entity manager factory ist not statically shared (@BeforeClass), but instead recreated for each test (@Before), but this leads to the fact that the integration test's underlying JDBC connection is to be reestablished for each test, what makes the suite run rather slow. It does not work to inversly statically share (@BeforeClass) the entity manager, as the problem still occurs then. It would be really great if the EclipseLink team could find a solution for this problem, as JUnit is a rather well-known and widely used testing tool, and tests should run as fast as possible (without JDBC reconnect).
Deferring.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
