Is there a way to scan JPA entities not to declare persistent classes in a persistence.xml file?

Question

I would like to take advantage of JPA @Entity annotations not to declare class entities a J2SE persistence.xml file. What I'd like to avoid :

<persistence-unit name="test" transaction-type="RESOURCE_LOCAL">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <class>com.mycompany.entities.Class1</class>
    <class>com.mycompany.entities.Class2</class>
    <class>com.mycompany.entities.Class3</class>
</persistence-unit>

and here is what my actual persistence.xml look alike

    <persistence-unit name="test" transaction-type="RESOURCE_LOCAL">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <properties>
        <!-- Scan for annotated classes and Hibernate mapping XML files -->
        <property name="hibernate.archive.autodetection" value="class, hbm" />
        <property name="hibernate.cache.use_second_level_cache" value="false" />
        <property name="hibernate.cache.use_query_cache" value="false" />
        <property name="hibernate.hbm2ddl.auto" value="create-drop" />
    </properties>
</persistence-unit>

Is there a standard way to scan JPA entities in a persistence.xml file from within a JAR module? Is there a unstandard Hibernate way to scan JPA entities in a persistence.xml file from within a JAR module?

Vernita

Answer 1

-Make sure your entities and persistence.xml end up in the same classpath when you build your jar.

The entities cannot be scanned if they are sitting in another classpath. If you need to have them sitting in different classpaths, heres one trick I've seen to make it work: No autodetection of JPA Entities in maven-verify.

If you are unsure where things are ending, you can unzip the .jar file and peak. This is an unpacked persistence web project:

Notice my classes are down the com directory, and my persistence.xml is in the META-INF directory. Both are in the same 'classes' classpath, so autoscan will work.

-Set hibernate.archive.autodetection property.

<!-- Scan for annotated classes and Hibernate mapping XML files -->
<property name="hibernate.archive.autodetection" value="class, hbm" />

-Add false to the persistence-unit

<persistence-unit name=...>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
    ...

Hopefully one of those will work for you.

Mccullers

Yes it looks like that, but it doesn't work in my case. Here is the definition of the property hibernate.archive.autodetection : "Determine which element is auto discovered by Hibernate Entity Manager while parsing the .par archive. (default to class,hbm).". But what is a .par archive? I've never heard of such an arhive. – Vernita

The .par archive is persistence archive file where your entities and persistence.xml can be bundled. It is not required, so dont worry about it (see the last post from a Hibernate team member here: forum.hibernate.org/viewtopic.php?f=9&t=947671). Another suggestion would be to add: <exclude-unlisted-classes>false</exclude-unlisted-classes> to your persistence-unit. – Mccullers

I've updated my answer as well. Make sure your classes and persistence.xml are in the same classpath (see the first bullet). – Mccullers

I get the same structure than one you described, and weirdly it doesn't seem to work in my case. But after taking a glance at the description of <exclude-unlisted-classes> element, it is said that this property is not applicable to Java SE persistence units. Maybe the problem is that I'm accessing EJB within a test environment (unitils + dbunit + junit), outside an EJB container. – Vernita

I've found the origin of the problem. As you warned me before, the entities I was testing were not in the same classpath than the test class. – Vernita

Unfortunately, with Hibernate, any value of <exclude-unlisted-classes> apparently sets the value to true, so you need to omit this element if you want a (default) value of false. See PersistenceXmlLoader – Perfidy

Property documented in javadoc : org.hibernate.cfg.AvailableSettings#SCANNER_DISCOVERY – Swound

maybe when you say "classpath" you mean "classloader" ? a JVM has a single classpath but multiple classloaders – Clemens