Spring Boot 1.4 : class path resource [] cannot be resolved to URL because it does not exist

[andrashatvani]

The project only indirectly uses components with persistence i.e. there are no entities directly in use. With Spring Boot 1.3.4 there was no need for any kind of persistence configuration.
However, upon having upgraded to Spring Boot 1.4 I've encountered the following exception:

2016-07-31_19:29:21.758 [main] ERROR org.springframework.boot.SpringApplication - Application startup failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaAutoConfiguration.class]: Invocation of init method failed; nested exception is javax.persistence.PersistenceException: Unable to resolve persistence unit root URL
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1076) ~[spring-context-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:851) ~[spring-context-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:541) ~[spring-context-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:122) ~[spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:759) [spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:369) [spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:313) [spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1185) [spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1174) [spring-boot-1.4.0.RELEASE.jar!/:1.4.0.RELEASE]
    at at.oebb.ticketshop.automat.backend.Application.main(Application.java:21) [classes!/:na]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_31]
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[na:1.8.0_31]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:1.8.0_31]
    at java.lang.reflect.Method.invoke(Unknown Source) ~[na:1.8.0_31]
    at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48) [ts-automat-0.0.1.jar:na]
    at org.springframework.boot.loader.Launcher.launch(Launcher.java:87) [ts-automat-0.0.1.jar:na]
    at org.springframework.boot.loader.Launcher.launch(Launcher.java:50) [ts-automat-0.0.1.jar:na]
    at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:58) [ts-automat-0.0.1.jar:na]
Caused by: javax.persistence.PersistenceException: Unable to resolve persistence unit root URL
    at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl(DefaultPersistenceUnitManager.java:603) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.preparePersistenceUnitInfos(DefaultPersistenceUnitManager.java:443) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.afterPropertiesSet(DefaultPersistenceUnitManager.java:424) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:310) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:373) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:362) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574) ~[spring-beans-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    ... 24 common frames omitted
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:187) ~[spring-core-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl(DefaultPersistenceUnitManager.java:600) ~[spring-orm-4.3.1.RELEASE.jar!/:4.3.1.RELEASE]
    ... 31 common frames omitted

I could fix the issue by the following:

• @EnableAutoConfiguration(exclude=HibernateJpaAutoConfiguration.class) must be set on the application class
• spring.data.jpa.repositories.enabled=false must be set in the application properties/yml.

[snicoll]

@andrashatvani that's not helping much I am afraid. On #6314 I asked for more details and the stacktrace doesn't give us anything that we don't know already. A sample that reproduces the problem and illustrates why it's not the same thing as #6314 would help.

[linzhaoming]

I have the same problem before. Before upgrading, I was using the starter spring-boot-starter-data-jpa. And the older version is 1.3.5.RELEASE.

With old version 1.3.5.RELEASE, my APP is OK. After upgrading to 1.4.0.RELEASE, my app can not start and report the same problem.

After some debugging, I found the key difference is the maven plugin: spring-boot-maven-plugin.

There has 2 solutions:
Solution 1. Force the spring-boot-maven-plugin to use the old version, I am using 1.3.5.RELEASE
Solution 2. exclude the jpa dependency: I replace the previous spring-boot-starter-data-jpa to use starter spring-boot-starter-jdbc instead.

The two solution can both fix my problem. But I choose Solution 2 in my app. Because I want to catch up with the newer RELEASE version. And my application doesn't use jpa function

[cbelleza]

If you have an EntityManagerFactory without a real package folder with entities defined this error happens.

[jeesun]

@linzhaoming Thank you.With your solution 2,i succeed to run the jar my application generated.

[snicoll]

@andrashatvani I guess mvn spring-boot:run and running your app in the IDE works, it only fails when it's ran via the fat jar. If so, it would have been nice to say so. If it fails in the IDE, please share a sample because we're definitely not talking about the same problem.

The problem is the new layout in 1.4 that doesn't give any fallback options for Spring Framework to compute the persistence unit url. So we'd have to populate setDefaultPersistenceUnitRootLocation with a valid url somehow

(more details for those interested: the way we build the persistence unit makes it so that this URL is actually not used but the JPA implementation has to check that it is specified so we need to give some sort of URL. That's why this fallback code exists in the first place).

[snicoll]

I am trying to define an URI that makes sense. Based on @wilkinsona's feedback, I am trying to get the location of the main Spring Boot application class. I've implemented something that is ok-ish. Unfortunately, Hibernate does not like it:

java.io.FileNotFoundException: /Users/snicoll/workspace/scratches/test-jpa-no-entities/target/test-jpa-no-entities-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes (No such file or directory)
        at java.util.zip.ZipFile.open(Native Method) ~[na:1.8.0_92]
        at java.util.zip.ZipFile.<init>(ZipFile.java:219) ~[na:1.8.0_92]
        at java.util.zip.ZipFile.<init>(ZipFile.java:149) ~[na:1.8.0_92]
        at java.util.jar.JarFile.<init>(JarFile.java:166) ~[na:1.8.0_92]
        at java.util.jar.JarFile.<init>(JarFile.java:103) ~[na:1.8.0_92]
        at org.hibernate.boot.archive.internal.JarFileBasedArchiveDescriptor.resolveJarFileReference(JarFileBasedArchiveDescriptor.java:165) ~[hibernate-core-5.0.9.Final.jar!/:5.0.9.Final]
        at org.hibernate.boot.archive.internal.JarFileBasedArchiveDescriptor.visitArchive(JarFileBasedArchiveDescriptor.java:51) ~[hibernate-core-5.0.9.Final.jar!/:5.0.9.Final]
        at org.hibernate.boot.archive.internal.JarProtocolArchiveDescriptor.visitArchive(JarProtocolArchiveDescriptor.java:59) ~[hibernate-core-5.0.9.Final.jar!/:5.0.9.Final]
        at org.hibernate.boot.archive.scan.spi.AbstractScannerImpl.scan(AbstractScannerImpl.java:47) ~[hibernate-core-5.0.9.Final.jar!/:5.0.9.Final]

I am running out of options there... A FailureAnalyzer is my next solution but it would be nice if we could prevent that exception from happening in the first place.

[jhoeller]

Persistence providers expect a jar file reference there, which is why DefaultPersistenceUnitManager adapts any such URI through ResourceUtils.extractJarFileURL first. This might work here as well.

[snicoll]

I should note for the record that @jhoeller gave me that trick last week and I already forgot about it. Thanks Juergen, tried that and it worked. The code requested to get that working is a bit convoluted so I'll push that to a branch and check with the team what we can do to improve it.

[philwebb]

I'm a little worried that the new ApplicationInfo class will end up being SpringApplication lite. I wonder if we should either expose a much more limited ApplicationMainClass bean, or alternatively just directly publish SpringApplication itself as a bean?

I have some reservation about the second option.

[snicoll]

I, for sure, didn't want to expose SpringApplication. It's mutable and most the stuff you'd change there once the app has started would have no effect. Maybe ApplicationInfo could be an interface that SpringApplication implements? This would still allow you to get the implementation though.

[philwebb]

I have the same concerns about exposing SpringApplication.

[philwebb]

I think we should hold off on adding the ApplicationInfo class for now. I've reworked things in https://github.com/philwebb/spring-boot/tree/gh-6635 to register the main application class directly as a bean instead.

[snicoll]

This goes in the opposite direction of not adding too much singleton beans to the context. I can see some serious improvements in that commit but registering the class as a singleton is not one of them IMO.

[snicoll]

I've reworked your proposal and removed the registration of the main application class. We're using the class of the auto-configuration now. I've also reverted the other changes related to ApplicationInfo in the documentation and the remote shell support. Those two commits combined adds a minimal change in the builder and JpaBaseConfiguration. Thanks a lot for polishing the initial proposal!

[znikola]

I've seen that fix to this issue has been included in 1.4.1 release, but after upgrade I'm still having this problem.

Caused by: java.io.FileNotFoundException: class path resource [] cannot be resolved to URL because it does not exist

EDIT: We are using hbm.xml files for our entity mapping, which means that we have POJO classes as a model without any annotation in them. But, we are using Spring Data JPA repositories.

[wilkinsona]

@znikola Are you sure you've successfully upgraded to 1.4.1.RELEASE? I cannot reproduce the problem any more. If you can, please open a new issue with a sample that shows how to do it and we'll take a look.

[znikola]

Yes, upgrade was successful and everything is cleaned and rebuild again. I'll create new project on GitHub and just link it in new issue, so that you can reproduce it. Is that OK?

[wilkinsona]

I'll create new project on GitHub and just link it in new issue, so that you can reproduce it. Is that OK?

Perfect. Thank you.

[znikola]

@wilkinsona I uploaded project in this (#6983) issue since it could be related.

Sorry that this took so long to respond.

[fjordansilva]

Same issue for me using Spring Boot 1.4.1.RELEASE
I'm trying to load an external properties file placed in the same folder as the app uber jar.

[wilkinsona]

@fjordansilva That doesn't sound like the same issue to me. This issue is specifically related to JPA and loading an external properties file should not be affected. If you need some help with that, I'd recommend posting a question on Stack Overflow.

[fjordansilva]

Ok, thanks, I'll do it

[patexoid]

Got the same issue on 1.4.2.RELEASE.
1.4.1.RELEASE works fine
full log https://travis-ci.org/patexoid/ZombieLib2/jobs/175686754

[snicoll]

@patexoid that looks weird and this issue is closed anyway. Please create a new issue with a sample that reproduces the issue since we've been investigating quite a lot of use cases and apparently you found yet another one.

[nmorado]

seems like an issue in 1.5.4.RELEASE?

[wilkinsona]

@nmorado As shown by the fact that this issue is closed, we believe it is fixed. If you think that's not the case please open a new issue with a sample that reproduces the problem.