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.