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