[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipselink-users] Abstract entities, revisited
|
I was not registered on the mailing list, so I couldn't reply to the thread at http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04346.html
I'm also facing this issue: we have several abstract base entities with and concrete subclasses, and we are migrating to Glassfish v3.
EclipseLink raises an error indicating that there should be a public no-arg constructor, or there was an error invoking the constructor.
However, the JPA 2.0 specification states, on section 2.11.1 Abstract Entity Classes:
"An abstract class can be specified as an entity. An abstract entity differs from a concrete entity only in
that it cannot be directly instantiated. An abstract entity is mapped as an entity and can be the target of
queries (which will operate over and/or retrieve instances of its concrete subclasses).
An abstract entity class is annotated with the Entity annotation or denoted in the XML descriptor as
an entity."
About the question by Tom Ware on http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg04349.html asking "What is the behavior when one of these objects is read from the database? i.e. if neither of the subclasses is an entity, what is the class of the instance you get back from the DB when you read?", probably there should be a validation that abstract entities have at least one concrete subclass in the same entity manager factory. Otherwise, runtime exceptions could be raised.
Shouldn't the TCK tests catch things like this?
Luis Fernando Planella Gonzalez
