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

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

Closed
dmikusa opened this issue Apr 13, 2015 · 23 comments
Closed
Labels

Comments

@dmikusa
Copy link

dmikusa commented Apr 13, 2015

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
Copy link

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
Copy link
Author

dmikusa commented Apr 13, 2015

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
Copy link

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 added a commit to philwebb/cli that referenced this issue Apr 14, 2015
@philwebb
Copy link

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
Copy link

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
Copy link
Contributor

goehmen commented Apr 28, 2015

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

@goehmen goehmen closed this as completed Apr 28, 2015
@philwebb
Copy link

@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
Copy link

@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?

@goehmen goehmen reopened this May 1, 2015
@cf-gitbot
Copy link

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
Copy link
Contributor

goehmen commented May 1, 2015

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).

@camelpunch camelpunch added the bug label Sep 15, 2015
@krishicks
Copy link
Contributor

@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
Copy link

dkoper commented Nov 4, 2015

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.

@dkoper dkoper closed this as completed Nov 4, 2015
@philwebb
Copy link

philwebb commented Nov 5, 2015

@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
Copy link
Contributor

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.

@krishicks krishicks reopened this Nov 6, 2015
@dkoper
Copy link

dkoper commented Nov 8, 2015

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

@jdubois
Copy link

jdubois commented Nov 9, 2015

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

@dmikusa
Copy link
Author

dmikusa commented Nov 18, 2015

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.

simonleung8 pushed a commit that referenced this issue Nov 18, 2015
See #411 (comment)
for background.

[#93671532]

Signed-off-by: Kris Hicks <khicks@pivotal.io>
simonleung8 pushed a commit that referenced this issue Nov 19, 2015
See #411 (comment)
for background.

[#93671532]

Signed-off-by: Kris Hicks <khicks@pivotal.io>
@dkoper
Copy link

dkoper commented Nov 20, 2015

@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
Copy link
Author

dmikusa commented Nov 23, 2015

Works for me with the edge binary. Thanks!

@dkoper
Copy link

dkoper commented Nov 23, 2015

Thanks Dan for the quick confirmation!

@dkoper dkoper closed this as completed Nov 23, 2015
@philwebb
Copy link

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

@krishicks
Copy link
Contributor

😓

@dkoper
Copy link

dkoper commented Dec 23, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants