spring-boot jersey based application : can not start without errors using java -jar command

[boostrack]

It works fine if I run it using:

OK: mvn spring-boot:run

but not relying on the spring-boot maven plugin and with a plain:

NOK : java -jar target/spring-boot-jersey-test-0.0.1-SNAPSHOT.jar

For the 2nd case, App starts but the following errors are visible during startup

[2014-08-07 12:54:47.531] boot - 7632 ERROR [localhost-startStop-1] --- [/]: Exception starting filter servletContainer
com.sun.jersey.core.spi.scanning.ScannerException: IO error when scanning jar jar:file:/Users/boostrack/spring-boot-jersey-test/target/spring-boot-jersey-test-0.0.1-SNAPSHOT.jar!/lib/jersey-client-1.11.jar!/com/sun/jersey
    at com.sun.jersey.core.spi.scanning.uri.JarZipSchemeScanner.scan(JarZipSchemeScanner.java:82)
    at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:223)
    at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:139)
    at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
    at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
    at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
    at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
    at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:700)
    at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:678)
    at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:203)
    at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:374)
    at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:727)
    at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:109)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4809)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5485)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.FileNotFoundException: /Users/boostrack/spring-boot-jersey-test-0.0.1-SNAPSHOT.jar!/lib/jersey-client-1.11.jar (No such file or directory)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(FileInputStream.java:131)
    at java.io.FileInputStream.<init>(FileInputStream.java:87)
    at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
    at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
    at java.net.URL.openStream(URL.java:1038)
    at com.sun.jersey.core.spi.scanning.uri.JarZipSchemeScanner.closing(JarZipSchemeScanner.java:123)
    at com.sun.jersey.core.spi.scanning.uri.JarZipSchemeScanner.scan(JarZipSchemeScanner.java:75)
    ... 22 more
[2014-08-07 12:54:47.558] boot - 7632 ERROR [localhost-startStop-1] --- StandardContext: Error filterStart
[2014-08-07 12:54:47.560] boot - 7632 ERROR [localhost-startStop-1] --- StandardContext: Context [] startup failed due to previous errors

and the application does not respond as expected.

PS: did not tested how it works with gradle plugin

[wilkinsona]

In the future please ask this sort of question on StackOverflow using the spring-boot tag.

It looks like you've configured Jersey to scan the com.sun.jersey package. The jars containing that package are nested within your application's jar file and Jersey appears to be unable to scan a nested jar.

If you need Jersey to scan the com.sun.jersey package then you can configure Boot's Maven plugin to unpack the jars containing that package:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <requiresUnpack>
                <dependency>
                        <groupId>com.sun.jersey</groupId>
                        <artifactId>jersey-server</artifactId>
                </dependency>
                <dependency>
                        <groupId>com.sun.jersey</groupId>
                        <artifactId>jersey-core</artifactId>
                </dependency>
                <dependency>
                        <groupId>com.sun.jersey</groupId>
                        <artifactId>jersey-servlet</artifactId>
                </dependency>
        </requiresUnpack>
    </configuration>
</plugin>

See the documentation for more details.

[btiernay]

With 1.2.0.M2 I can't seem to get the same effect when using the following with Gradle:

apply plugin: 'spring-boot'

springBoot {
  requiresUnpack = [ "com.google.guava:guava" ]
}

It simply doesn't unpack in the resulting jar.

Actually, I can't see where requiresUnpack is consumed in Spring Boot:

https://github.com/spring-projects/spring-boot/search?utf8=%E2%9C%93&q=requiresUnpack

[btiernay]

From http://docs.spring.io/autorepo/docs/spring-boot/1.2.0.M2/reference/html/build-tool-plugins-gradle-plugin.html#build-tool-plugins-gradle-configuration-options

requiresUnpack A list of dependencies (in the form ``groupId:artifactId'' that must be unpacked from fat jars in order to run. Items are still packaged into the fat jar, but they will be automatically unpacked when it runs.

I'm not exactly sure how to interpret that actually. Is "it runs" referring to the execution repackaged jar or the execution of bootRepackage task?

[wilkinsona]

@btiernay That search shows the two places where requiresUnpack is consumed. One in the Maven plugin and one in the Gradle plugin.

It simply doesn't unpack in the resulting jar

That's not the intention of requiresUnpack. Any dependency marked with requiresUnpack will be unpacked at runtime. This is explained in the documentation:

Most nested libraries in an executable jar do not need to be unpacked in order to run, however, certain libraries can have problems. For example, JRuby includes its own nested jar support which assumes that the jruby-complete.jar is always directly available as a file in its own right.

To deal with any problematic libraries, you can flag that specific nested jars should be automatically unpacked to the ‘temp folder’ when the executable jar first runs.

[btiernay]

@wilkinsona Thanks for the explanation. I guess I must have missed that section in the docs.

With regard to the Gradle plugin, I still don't see where requiresUnpack is actually used. I would have thought it would have been consumed in https://github.com/spring-projects/spring-boot/blob/f97251b9cf80aa5cda21340d6cbcd28852db5c14/spring-boot-tools/spring-boot-gradle-plugin/src/main/groovy/org/springframework/boot/gradle/repackage/RepackageTask.java.

[wilkinsona]

It's here