Additionally, although the error chides me for not defining a public
no-arg constructor (which I do, by the way), it is legal to have an
@Entity that declares only a protected no-arg constructor.
Best,
Laird
On Sun, Mar 21, 2010 at 1:38 PM, Laird Nelson <ljnelson@xxxxxxxxx
<mailto:ljnelson@xxxxxxxxx>> wrote:
I have a case that is handled just fine by both Hibernate and
OpenJPA (their JPA 2.0 implementations) and cannot be handled by
EclipseLink 2.0.0.
I have an abstract @Entity class.
Then I have two concrete subclasses that are not defined as entities
and do not add any state (they just override behavior).
I am running this scenario in a non-Java-EE environment.
EclipseLink barfs on EntityManagerFactory initialization, claiming
that some class does not have a public no-argument constructor,
which is false. Here is the stack trace:
Local Exception Stack:
Exception [EclipseLink-34] (Eclipse Persistence Services -
2.0.0.v20091127-r5931):
org.eclipse.persistence.exceptions.DescriptorException
Exception Description: This class does not define a public default
constructor, or the constructor raised an exception.
Internal Exception: java.lang.InstantiationException
Descriptor:
RelationalDescriptor(com.jenzabar.ngp.identity.jpa.AbstractPassiveReference
--> [DatabaseTable(reference)])
at
org.eclipse.persistence.exceptions.DescriptorException.instantiationWhileConstructorInstantiation(DescriptorException.java:724)
at
org.eclipse.persistence.internal.descriptors.InstantiationPolicy.buildNewInstanceUsingDefaultConstructor(InstantiationPolicy.java:139)
at
org.eclipse.persistence.internal.descriptors.InstantiationPolicy.buildNewInstance(InstantiationPolicy.java:103)
at
org.eclipse.persistence.descriptors.ClassDescriptor.selfValidationAfterInitialization(ClassDescriptor.java:3519)
at
org.eclipse.persistence.descriptors.ClassDescriptor.validateAfterInitialization(ClassDescriptor.java:5247)
at
org.eclipse.persistence.descriptors.ClassDescriptor.postInitialize(ClassDescriptor.java:3241)
at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:463)
at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:406)
at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:671)
at
org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.login(DatabaseSessionImpl.java:633)
at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:230)
at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:368)
at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:151)
at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:207)
at
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:195)
What is happening here?
The JPA 2.0 specification says--explicitly--that entities may be
abstract, and their subclasses may be concrete, so I would expect
that this case should work.
Thanks,
Laird
------------------------------------------------------------------------
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users