Package JPA with orm.xml fails with odd error: "cannot be resolved to URL because it does not exist" in Spring-Boot 1.4.0.M2

[pavax]

Since we updated from spring-boot 1.3.3 to 1.4.M2 we receive a odd exception if we start our application by packing it into a execuatable jar (or war). This problem only occurs if you don't scan for any entities in your classpath but rather define the mapping in a orm.xml. The Bug seems to be similar to an already fixed one: #420

Everything works if we start the Application with the Application.java main method or if we deploy the (execuatable) war file to tomcat. The problem does not occur if there has been at least one Entity defined/scanned by using the javax.persistence annotations

Tested Versions
Spring Boot Version 1.4.0.M2
Spring Boot Version 1.3.3 (works)

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:187)
        at org.springframework.orm.jpa.persistenceunit.DefaultPersistenceUnitManager.determineDefaultPersistenceUnitRootUrl(DefaultPersistenceUnitManager.java:588)
        ... 31 common frames omitted

Example Project:
https://github.com/pavax/sample-spring-boot-app

Howto

1. mvn clean install
2. start the application java -jar sample-spring-boot-app.jar

alternatively: change the packaging of the sample-spring-boot-web to war and active the profile executable-war.

[philwebb]

@wilkinsona Looks like 87fe0b2 removed that hack. We could put it back I guess but I wonder if there's a better way?

[wilkinsona]

I think there's a bit more to this one. 87fe0b2 removed the hack but it left the tests that were added in the fix for #420 in place. For example, this passes:

@Test
public void resolveRootPathFromArchive() throws Exception {
    LaunchedURLClassLoader loader = new LaunchedURLClassLoader(
            new URL[] { new URL("jar:file:src/test/resources/jars/app.jar!/") },
            getClass().getClassLoader());
    assertThat(loader.getResource("")).isNotNull();
}

[wilkinsona]

The same problem occurs with a shaded jar so I don't think that LaunchedURLClassLoader, or anywhere in our loader for that matter, is the ideal place to fix this. I'm not sure where the ideal place is, though.

[wilkinsona]

Tomcat produces a URL for the root of the classpath even when the host is configured with unpackWARs=false and it's loading classes straight from an archive. The URL is of the form jar:file:/path/to/the.war!/WEB-INF/classes/.

[wilkinsona]

The problem only happens when Boot's JarURLConnection is involved, i.e. when the URL has been obtained from an org.springframework.boot.loader.jar.JarFile.

getResourceFrom(new URL("jar:file:src/test/resources/jars/app.jar!/"));
getResourceFrom(new URL("jar:file:src/test/resources/jars/app.jar!/demo/"));
JarFile jarFile = new JarFile(new File("src/test/resources/jars/app.jar"));
getResourceFrom(jarFile.getUrl());
getResourceFrom(jarFile.getNestedJarFile(jarFile.getEntry("demo/")).getUrl());

private void getResourceFrom(URL url) {
    System.out.println(new URLClassLoader(new URL[] { url }, null).getResource(""));
    System.out.println(
            new LaunchedURLClassLoader(new URL[] { url }, null).getResource(""));
}

The above outputs:

null
null
jar:file:src/test/resources/jars/app.jar!/demo/
jar:file:src/test/resources/jars/app.jar!/demo/
null
null
null
null

For consistency with a standard JarURLConnection, the 7th and 8th entries should be non-null.

[wilkinsona]

Given that this affects shaded jars (where the class loader is out of Boot's control) I've opened https://jira.spring.io/browse/SPR-14246 to see if a more general purpose fix is possible.

[wilkinsona]

SPR-14246 won't be fixed in time for M3. Moving back to RC1.

[wilkinsona]

SPR-14246 has been fixed and the sample app works when configured to use Spring Framework 4.3.0.BUILD-SNAPSHOT. Boot's already building against those snapshots so there's nothing more to do to address this issue.

[masrawi]

I have the same issue with the current 1.4.0.BUILD-SNAPSHOT. it has to do with having the starter application class not in the root package. with 1.3.5 it works but with the latest build it does not
spring-boot-example-5842.zip

[wilkinsona]

@masrawi This issue's closed. Can you please open a new one?

[snicoll]

@masrawi your project is broken in both 1.3 and 1.4 for me. And I don't think it has anything to do with this issue. @SpringBootApplication(scanBasePackages = "base") is actually exactly the same thing as @ComponentScan({ "base" }) (so it's redundant). If I add @EntityScan("base") to your application, everything is working as expected (see the doc)

[masrawi]

@snicoll I know it is redundant. it is just there to demonstrate that both are not working. I never needed to use @EntityScan and it worked in all the projects with 1.3. for me 1.4 is broken as the same setting working with 1.3 is not working anymore

[masrawi]

@wilkinsona #6314