| Summary: | ClassCastException when using Teneo with EclipseLink 2.3.0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Luc H <luc_h> | ||||
| Component: | Teneo | Assignee: | Shaun Smith <shaun.smith> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | banzeletti, cidhawk, csabakoncz, mtaal | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Would like to add that running the JUnit tests as described at http://wiki.eclipse.org/Teneo/EclipseLink with EclipseLink 2.3.1 results in 24 failures, all of them because of this ClassCastException. Created attachment 205170 [details]
Fix for EclipseLink 2.3.1
Following Luc's diagnosis I was able to fix the exception. I also had to add a dependency on org.eclipse.persistence.jpa.osgi as EclipseLinkResourceImpl was unable to find an imported class otherwise.
This latter change makes this plugin (org.eclipse.emf.teneo.eclipselink) work only with EclipseLink distributions that have the osgi bundle (did not check which version it was introduced). A possible solution for supporting older releases would be to create fragments containing the sensitive classes and have the fragments depend on EclipseLink versions they are known to work with.
Forgot to mention that I have absolutely no knowledge of Teneo/EclipseLink internals, my fix is purely the imitation of the original code. The tests are all green now, however the patch must definitely be checked/reviewed. Would highly appreciate fix for Eclipselink 2.3.2 bundled with GF latest release (3.1.2)in order to propose Teneo/Eclipselink for new medium-sized project at the company I work for (insurance business). Closing eclipselink issues as EclipseLink is no longer maintained in newer Teneo releases. For using EclipseLink with EMF please consider the Texo project: http://wiki.eclipse.org/Texo |
Build Identifier: I've been struggling for a while now to get the following simple query up and running with EclipseLink 2.3.0 and Teneo 1.1/1.2 : Query query = entityManager.createQuery("SELECT f FROM Film f"); List<?> films = query.getResultList()); The getResultList() call results in a ClassCastException : org.eclipse.persistence.internal.indirection.UnitOfWorkQueryValueHolder cannot be cast to org.eclipse.emf.teneo.eclipselink.EmfOwnedValueHolder This exception is thrown at org.eclipse.emf.teneo.eclipselink.EmfTransparentIndirectionPolicy.setAttributeOwner(EmfTransparentIndirectionPolicy.java:42) This query works fine with EclipseLink 2.1.3. I've been doing some debugging and discovered that : 1) class "EmfTransparentIndirectionPolicy" (supplied by Teneo) is a subclass of "TransparentIndirectionPolicy" (package org.eclipse.persistence.internal.indirection, supplied by EclipseLink). 2) At some time in the process of building the result list, objects and attributes are being cloned, and it appears that the signature of method "cloneAttribute" in class "TransparentIndirectionPolicy" was changed in EclipseLink 2.3.0 (or 2.2.0), with the following consequences : - Before 2.3.0/2.2.0, method "cloneAttribute" in class "EmfTransparentIndirectionPolicy" would get called (an EmfUnitOfWorkValueHolder would be used), because there is an override of this method available. - There is no override for the signature of "cloneAttribute" in the 2.3.0 version of class "TransparentIndirectionPolicy", so the 'standard' EclipseLink method in class "TransparentIndirectionPolicy" is used, resulting in a UnitOfWorkQueryValueHolder instance being passed to the "setAttribute" method in class "EmfTransparentIndirectionPolicy", resulting in the above ClassCastException. I only found 1 post with a similar problem, but no solution, so I guess I'm doing something terribly wrong in configuring my persistence unit For the moment I'll stick to EclipseLink 2.1.3 but of course I would like to keep up with more recent versions. Reproducible: Always