Spring boot Repackage generates invalid war file

Overview of the issue

This is a follow up issue from https://github.com/jhipster/generator-jhipster/issues/4326 I’m having the exact same issue as described there, except that in my case i do need the executable one.

The issue comes as AWS Elastic Beanstalk unzips the war file and the unzip command returns an exit code 1.

You don’t need to deploy the runnable war in AWS EB in order to reproduce this issue. You could simply unzip the generated war file (not the .original one, but the executable one), and although all files get properly extracted, if we echo the last command exit reason we will get a 1.

It’s worth mentioning that having created a Spring Boot sample app, this issue is not observed.

Attached both AWS Elastic Beanstalk eb-commandprocessor.log, as well as a custom log when unzipping a local test app. eb-commandprocessor.txt unzip-output.txt

Motivation for or Use Case

Can’t deploy generated war file to AWS Beanstalk.

Reproduce the error

In order to reproduce the issue, simply create a new jhipster app (i’m currently using maven, although in linked issue its being used gradle), and after running ./mvnw clean package -Pprod, run the following command;

$ unzip target/app-0.0.1-SNAPSHOT.war 
$ echo $?

Related issues

https://github.com/jhipster/generator-jhipster/issues/4326

JHipster Version(s)

This happens with both Jhipster v3.12.1 as well as with v4.0.6. I know Jhipster v4.0.8 updates Spring boot’s to latest version, but even so i’m still getting the same behavior.

JHipster configuration

{
  "generator-jhipster": {
    "jhipsterVersion": "3.12.1",
    "baseName": "test",
    "packageName": "com.avaya.ept",
    "packageFolder": "com/avaya/ept",
    "serverPort": "8080",
    "authenticationType": "session",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "postgresql",
    "searchEngine": false,
    "messageBroker": false,
    "buildTool": "maven",
    "enableSocialSignIn": true,
    "rememberMeKey": "35a9882a9e9d9065c9fea0048ce9a31c9417f5fd",
    "useSass": false,
    "applicationType": "monolith",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": false
  }
}

Browsers and Operating System

MacOS El capitan

• Checking this box is mandatory (this is just to show you read everything)

[gmarziou]

Never too late, I had a close look to https://github.com/spring-guides/gs-spring-boot, I built the jar and looked at it in an editor: it does not include the executable script in header. So it confirms that the default is executable=false as documented in spring-boot maven plugin doc.

Official doc states:

It is recommended that you only make your jar or war fully executable if you intend to execute it directly, rather than running it with java -jar or deploying it to a servlet container.

Our Dockerfile uses java -jar, same for Heroku generator and our Travis builds, I’m not sure for CloudFoundry. Our doc mentions the 2 ways but I guess the executable jar is only useful to users (like me) deploying their apps as systemd services.

I think we could change the default value and generate pom.xml with a comment:

               <configuration>
                    <mainClass>${start-class}</mainClass>
                    <!-- set to true if you plan to deploy your app as systemd service -->
                    <executable>false</executable>
                    <fork>true</fork>
                </configuration>

WDYT @jdubois ?

[jdubois]

Well, the executable flag is cool, and I don’t think it causes any issue anymore, but I’m not sure because those were on some specific systems (like Jenkins)