Mention fully executable jars when warning about Jersey's scanning limitations

[lgawron]

I have a spring boot application (1.3.0.M1) with Jersey endpoints. As soon as I make the jar executable - the endpoints are not detected.

Using following configuration in pom.xml:

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <executable>true</executable>
                </configuration>
            </plugin>
        </plugins>
    </build>

gives me:

{"timestamp":1435928140519,"status":404,"error":"Not Found",
 "message":"Not Found","path":"/ws/auth/token"}

Same starts working as soon as I comment out <executable> tag

[philwebb]

Are you able to share an example project that replicates the issue?

[lgawron]

Sorry for such delay - I somehow missed your reply...

The problem actually goes down to:

@Configuration @ApplicationPath("ws")
public class JerseyConfig extends ResourceConfig {
    public JerseyConfig() {
        packages( "demo.rest" );
    }
}

This does not work for executable jar, works for standard one though. if you do register( HelloEndpoint.java ) instead it works in both cases. Somehow Jersey's package scanning is impaired when using executable jar.

I am attaching a simple project. Please build and navigate to http://localhost:8080/ws/hello

[lgawron]

Oops, I had no idea github does not allow attachments.
Here it is: dropbox link

[nodje]

not exactly the same issue, but related:
https://stackoverflow.com/questions/32431989/jersey-bug-when-starting-spring-boot-app-unix-style

[wilkinsona]

Jersey uses a JarInputStream to scan the jar. It doesn't fail, but the input stream thinks it has no entries. This will produce no output:

JarInputStream input = new JarInputStream(new FileInputStream("demo.jar"));
JarEntry entry;
while ((entry = input.getNextJarEntry()) != null) {
    System.out.println(entry);
}

Setting <executable>false</executable>, rebuilding, and re-running produces the expected list of entries from the jar.

[wilkinsona]

The problem appears to be specific to JarInputStream. JarFile successfully lists all the entries:

JarFile jarFile = new JarFile(new File("demo.jar"));
Enumeration<JarEntry> entries = jarFile.entries();
while (entries.hasMoreElements()) {
    System.out.println(entries.nextElement());
}
jarFile.close();

[wilkinsona]

ZipInputStream expects the first 32-bits of the file to be equal to ZipConstants.LOCSIG, ZipFile has no such limitation.

[wilkinsona]

The javadoc for Jersey's PackageNamesScanner suggests that we could plug in our own handler for jar URLs:

Further schemes may be registered by registering an implementation of
UriSchemeResourceFinderFactory in the META-INF/services file whose name is the
the fully qualified class name of UriSchemeResourceFinderFactory

However, the code tells a different story:

// TODO - Services?
// for (UriSchemeResourceFinderFactory s : ServiceFinder.find(UriSchemeResourceFinderFactory.class)) {
//     add(s);
// }