JPA without persistence.xml fails when all classpath items are jars [SPR-8832]

[spring-projects-issues]

Artem Troitskiy opened SPR-8832 and commented

LocalContainerEntityManagerFactoryBean with setPackagesToScan() and without persistence.xml fails when all classpath items are jars with the following exception:

Caused by: java.io.FileNotFoundException: class path resource [] cannot be resolved to URL because it does not exist
        at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:179)
        at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl(DefaultPersistenceUnitManager.java:426)

It doesn't fail if at least one classpath item is a folder.

It's caused by attempt to resolve a pattern pointing to the classpath root ("classpath:") that doesn't work for jars.

---

Affects: 3.1 RC1

Issue Links:

• Unable to resolve persistence unit root URL with LocalContainerEntityManagerFactoryBean [SPR-15304] #19869 Unable to resolve persistence unit root URL with LocalContainerEntityManagerFactoryBean
• DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl fails when run from a shaded jar [SPR-14246] #18819 DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl fails when run from a shaded jar

Referenced from: commits 62e5b9d

9 votes, 11 watchers

[spring-projects-issues]

Torsten Krah commented

This does still apply to 3.1.0.RELEASE and i would rate this one at major, because the complete classpath scan feature is broken which does render the app unusable if packaged via jar file.

[spring-projects-issues]

Juergen Hoeller commented

As of 3.1.1, we are using the containing jar as the persistence unit root URL for the default unit now, based on the location of the packages that we are scanning. We'll only fall back to the classpath root strategy if the jar determination doesn't work out.

Juergen

[spring-projects-issues]

Cristi Vulpe commented

It seems that the problem is still there with 3.1.1. Here are some details:
If I use this:

<bean id="myEntityManagerFactory"
  class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
  <property name="dataSource"defaultDataSource" ref="myDataSource" />
  <property name="persistenceUnitName"defaultPersistenceUnitName" value="myDb" />
  <property name="mappingResources" value="META-INF/my-orm-mapping.xml" />    
  <property name="jpaVendorAdapter">
    <bean
      class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
    </bean>
  </property>
  <property name="jpaProperties" ref="myOracleHibernatePoperties" />
</bean>

… I bump into the same error as originally reported…
However, I managed to circumvent it by using this:

  <bean id="myPUManager"
    class="org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager">
    <property name="defaultDataSource" ref="myDataSource" />
    <property name="defaultPersistenceUnitName" value="myDb" />
    <property name="mappingResources" value="META-INF/my-orm-mapping.xml" />
    <property name="defaultPersistenceUnitRootLocation"
      value="file://C:/tmp/jpa" />
  </bean>

  <bean id="myEntityManagerFactory"
    class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="persistenceUnitManager" ref="myPUManager" />
    <property name="jpaVendorAdapter">
      <bean
        class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
      </bean>
    </property>
    <property name="jpaProperties" ref="myOracleHibernatePoperties" />
  </bean>

Some details here:

• We don’t want to use persistence.xml at all and neither package scanning. What we want to do is to get the resources from mapping files (the reason is that we want to stay away from annotations because we might have two different legacy databases having different table names and column names)
• It seems that this line:

<property name="defaultPersistenceUnitRootLocation" value="file://C:/tmp/jpa" />

… fixes the situation (note that the C:/tmp/jpa is an empty folder).
I can leave with this workaround but I am not sure whether this will have some negative consequences. Can somebody provide a quick explanation here?

• Generally the approach we use is to stay away as much as we can from resources that reside in CLASSPATH (the reason is that we have many deployments and they all have different databases, folder structures etc.)

Let me know if you need more details about this.