cf push fails with jars generated with the Spring Boot 1.3.0 snapshot release

[dmikusa]

Steps to reproduce:

• Create new Maven project w/STS (I added Spring Boot Web Starter, but I don't think it's necessary), pick the 1.3.0 snapshot
• Run mvn package
• Run cf push <some-app-name> -p target/demo-0.0.1-SNAPSHOT.jar.

It will fail with the following:

 cf push my-boot-app -p target/demo-0.0.1-SNAPSHOT.jar
Updating app spring-boot-dan in org <org> / space development as <user>...
OK

Uploading <my-boot-app>...
FAILED
Error uploading application.
/var/folders/w4/g5kx6n_16330906jj_6nvqcc0000gp/T/apps009588947 is empty

The jar files can be extracted using a tool like jar or unzip and all of the files are present.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/92378762.

[dmikusa]

Here's a link to a demo project. You can use this instead of creating a new project in the repo instructions above.

https://drive.google.com/file/d/0Byv8UPk_0AMORS0zU1I4OXpsX1k/view?usp=sharing

[philwebb]

For a little more background on this issue and it's root cause see spring-projects/spring-boot#1117.

We are trying to use a little known technique with Spring Boot 1.3 of embedding a Bash script at the start of the jar file so that it can be easily run and installed as a service. The zip file format is a little unusual in that a central directory record is usually read from the end of the file, meaning that you can put whatever you want at the front. You can see how we deal with reading file by looking at this class.

I imagine that your unzip code or whatever library you use might need updating to deal with the additional bytes at the front of the file.

[philwebb]

I've updated one of the existing tests to reproduce the issue. See philwebb@a67df0d.

Unfortunately it looks like the root cause is coming from archive/zip in go itself which probably means there isn't going to be an easy fix.

[philwebb]

I've raised an issue with go and I have a possible fix. Perhaps this patched copy of archive/zip could be used by the CLI to work around the problem?

[goehmen]

We'll need to watch to see when Go picks up this fix. We're already looking to upgr to go 1.4.

[philwebb]

@goehmen So far they don't seem too keen to merge the fix. I need to find find out what techniques other tools use to deal with this. I'm stacked at the moment so If you have any time to add relevant feedback to golang/go#10464 please do.

[philwebb]

@goehmen The suggested patch isn't going to make Go 1.5 but an alternative fix as been suggested. Can we reopen this one to consider if it's possible to support this ourselves without waiting for Go?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/93671532.

[goehmen]

reopened.

Greg Oehmen
Cloud Foundry Product Manager

On Thu, Apr 30, 2015 at 2:43 PM, Phil Webb notifications@github.com wrote:

@goehmen https://github.com/goehmen The suggested patch isn't going to
make Go 1.5 but an alternative fix as been suggested
golang/go#10464 (comment). Can we
reopen this one to consider if it's possible to support this ourselves
without waiting for Go?

—
Reply to this email directly or view it on GitHub
#411 (comment).

[krishicks]

@philwebb: The cli unpacks the jar before uploading it. What would the expected behavior be with an embedded file in the jar after unpacking? How would it need to be uploaded?

[dkoper]

We're not going to add a dependency on a patched golang library that we then have to maintain ourselves.
Closing this issue as a won't-fix; we'll wait for a fix in golang.

[philwebb]

@krishicks The embedded script wouldn't actually need to be uploaded, It's can simply be ignored.
@dkoper You don't necessarily need to patch the golang library. golang/go#10464 (comment) suggests simply scanning forward for the 0x04034b50 header.

[krishicks]

Scanning for the headers seems like a fine thing to do, as @bradfitz says.

I'm going to re-open this for now. @dkoper should prioritize as he sees fit.

[dkoper]

@philwebb, @krishicks Thanks for the extra clarification. Sounds like there is a clear plan on how to tackle this.

[jdubois]

This is a huge issue for us ( jhipster/generator-jhipster#2225 ) as this means no JHipster application can be deployed to CloudFoundry.

[dmikusa]

FYI, the error on this seems different now. With Spring Boot 1.3.0 RELEASE & cf cli 6.13, I see this behavior.

Uploading demo-app...
FAILED
Error uploading application.
Server error, status code: 500, error code: 10001, message: An unknown error occurred.

When looking at the trace log, you can see that it's sending null to the resource_match api, which is what's causing the failure.

REQUEST: [2015-11-18T15:58:06-05:00]
PUT /v2/resource_match HTTP/1.1
Host: api.run.pivotal.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.13.0-e68ce0f / darwin

null

Disabling the executable JAR / WAR, makes this error go away.

    <build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <executable>false</executable>
                </configuration>
            </plugin>
        </plugins>
    </build>

Looking forward to a fix in the cli, so this won't be necessary.

[dkoper]

@dmikusa-pivotal , @philwebb We have made a fix. Can you try with our edge binary?
https://github.com/cloudfoundry/cli#downloads
Links are in the last paragraph.

Cheers,
Dies Koper
CF CLI PM

[dmikusa]

Works for me with the edge binary. Thanks!

[dkoper]

Thanks Dan for the quick confirmation!

[philwebb]

Sweet. Thanks @dkoper & @simonleung8 for the fix. I realize this is a bit of an edge case so I really appreciate it 👍

[krishicks]

😓

[dkoper]

This fix is included in cf CLI release v6.14.1 published today.
https://github.com/cloudfoundry/cli#downloads