Community
Participate
Working Groups
I have a persistence.xml with the model.Foo class listed where model.Foo is final. If you select the Foo class you will see that the JPA structure and details views are empty because we are considering this class not persistent. The persistence.xml file has an error on the model.Foo class: Class model.Foo cannot be resolved. We instead need to give a validation error on the class itself saying that an Entity class cannot be final. <persistence-unit name="Example"> <class>model.Foo</class> </persistence-unit> @Entity public final class Foo{ }
EclipseLink supports final Entities, so only the Generic platform should have an error or maybe even just a warning that this isn't portable/spec compliant.
We should investigate this for RC3 given that this would greatly limit functionality for users with final Entities in their models and the bug has no reasonable workaround.
Created attachment 169531 [details] proposed patch against head This patch simply changes the JPTTools.typeIsPersistable() method to return true for final classes. Very low risk change. The new validation error that we need to add is covered under bug 132216.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This bug prevents an EclipseLink user from mapping final entity classes with Dali. This is a major limitation if you are using mapped final classes in your application. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Fix has been manually tested and test case has been updated. * Give a brief technical overview. Who has reviewed this fix? See comment 3 for details. I have reviewed the fix. * What is the risk associated with this fix? Very low.
When was this check for the final modifier introduced? Was it in the current development cycle? Doesn't removing this check introduce a regression for the Generic Platform? At least I would expect that bug 132216 will be targeted to something closer than "Future".
(In reply to comment #5) > When was this check for the final modifier introduced? Was it in the current > development cycle? The check was added toward the end of the Galileo release, so this issue has existed in Galileo. > > Doesn't removing this check introduce a regression for the Generic Platform? At > least I would expect that bug 132216 will be targeted to something closer than > "Future". Yes, although calling it a regression might be too strong. The validation is the real solution to the generic case, as opposed to simply ignoring the entity. It seems reasonable in this case to allow these entities to exist in both cases in order to avoid restricting EclipseLink functionality. The slight evil of allowing these entities in Generic (where they are potentially invalid) is outweighed by the good of allowing proper EclipseLink functionality (where there is no workaround) in this case IMO. I have targeted bug 132216 to our "next release" bucket as this does need to be fixed as soon as possible.
checked in to head
Verified final classes are allowed in RC3
