Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that extracting layers with layertools doesn't work with executable JAR files #22993

Closed
pvorb opened this issue Aug 18, 2020 · 2 comments
Assignees
Labels
type: documentation A documentation update
Milestone

Comments

@pvorb
Copy link
Contributor

pvorb commented Aug 18, 2020

I'm using Spring Boot 2.3.3.

I've got a project where I'm building a fat JAR using the spring-boot-maven-plugin. I've configured the JAR to be executable and I've explicitly enabled layers. This is my configuration of the spring-boot-maven-plugin:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <executable>true</executable>
        <layers>
            <enabled>true</enabled>
        </layers>
    </configuration>
    <executions>
        <execution>
            <id>repackage</id>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

After building the project with mvn package, I try to extract the layers java -Djarmode=layertools -jar target/my-project-0.1.0-SNAPSHOT.jar extract --destination dest as described in this blog post on spring.io.

This gives me an empty directory for each of the layers:

$ ls -R dest
dest:
application  dependencies  snapshot-dependencies  spring-boot-loader

dest/application:

dest/dependencies:

dest/snapshot-dependencies:

dest/spring-boot-loader:

I would expect the directories to contain the class files of the different layers instead.

I noticed that this is caused by the JAR file being executable. I debugged through ExtractCommand.java and ZipInputStream#getNextEntry() will always return null for an executable JAR.

I think the options are to either improve the ExtractCommand (and possibly other commands) to work with executable JARs or to give a disclaimer in the documentation that the layertools don't work with executable JARs.

A fix could involve the following steps:

  • Call mark(2) on the FileInputStream to be able to later reset it in case the file is not executable.
  • Read the first two bytes from the FileInputStream and check if they match the "shebang" (#!) magic number (0x23 0x21).
  • In case the file doesn't start with a shebang, reset the input stream.
  • In case the file starts with a shebang, read bytes until the characters \necho 0 are read.
  • Wrap the input stream in a ZipInputStream and read the entries like before.

I know that this implementation won't be that easy, so I'd totally understand if you chose not to support executable JARs.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 18, 2020
@scottfrederick
Copy link
Contributor

This is similar to #22223.

For Spring Boot 2.3.x, we should detect this condition in layertools and give a warning or error like we do for the bootBuildImage task.

For Spring Boot 2.4.x, we're hoping to be able to fix up the jar file properly in #22336.

@scottfrederick scottfrederick added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 18, 2020
@scottfrederick scottfrederick added this to the 2.3.x milestone Aug 18, 2020
@scottfrederick scottfrederick self-assigned this Aug 18, 2020
@scottfrederick scottfrederick modified the milestones: 2.3.x, 2.3.4 Aug 18, 2020
@snicoll snicoll changed the title Extracting layers with layertools doesn't work with executable JAR files Document that extracting layers with layertools doesn't work with executable JAR files Aug 19, 2020
@snicoll snicoll added type: documentation A documentation update and removed type: bug A general bug labels Aug 19, 2020
@snicoll
Copy link
Member

snicoll commented Aug 19, 2020

I've switched this issue to documentation as keeping it as described made me think we've actually fixed that limitation.

philwebb added a commit that referenced this issue Aug 19, 2020
Update `ExtractCommandTests` so that the writer is closed after the
contents have been written.

See gh-22993
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

4 participants