Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Nov 9, 2011 · 3 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 9, 2011

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:

Referenced from: commits 62e5b9d

9 votes, 11 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 19, 2012

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
Copy link
Collaborator Author

spring-projects-issues commented Feb 7, 2012

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
Copy link
Collaborator Author

spring-projects-issues commented Sep 5, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants