Generator-jhipster: Cannot run application with prod profile using Spring.profiles.active option

[wmarques]

Overview of the issue

All is in the title, I ran mvn package -Pprod then java -jar -Dspring.profiles.active=prod target/*.warand it outputs me that I run with profiles dev, prod, which is not possible so the app crashes.

But if i run mvn -Pprod it works fine in prod profile.

JHipster Version(s)

master

JHipster configuration, a .yo-rc.json file generated in the root folder

{
  "generator-jhipster": {
    "jhipsterVersion": "2.27.0",
    "baseName": "appNoDb",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8081",
    "authenticationType": "jwt",
    "hibernateCache": "no",
    "databaseType": "no",
    "devDatabaseType": "no",
    "prodDatabaseType": "no",
    "searchEngine": "no",
    "buildTool": "maven",
    "jwtSecretKey": "bd1181a3e131b331d4251810c997c0a4e80e614b",
    "enableTranslation": false,
    "applicationType": "microservice",
    "testFrameworks": [
      "gatling"
    ],
    "skipClient": true,
    "skipUserManagement": true
  }
}

Browsers and Operating System

Ubuntu 14.04

Reproduce the error

Run above commands.

[notflorian]

I also had this issue recently, and I solved it by running java -jar target/*.war --spring.profiles.active=prod instead, as it is written in the production documentation

[jdubois]

Oh yes, sorry @wmarques I forgot about that.
I have no idea why --spring.profiles.active=prod works and not -Dspring.profiles.active=prod... But yes that's how it has always worked.
So I guess we should close this as "not a bug", but that's really misleading (if I'm getting wrong with it - and I wrote that documentation!! - then most people could get wrong), and I'd like to understand with the -D doesn't work.

[pascalgrimaud]

The documentation is correct
-D is used for JAVA_OPTS

[erikkemperman]

Sorry to comment on closed issue, but I was thinking that since the war is now exclusively dev or prod, the prod one really shouldn't require an additional argument... Having said that, I have not yet thought of a clean way to implement this, but first wanted to ask if anyone agrees this makes sense?

[jdubois]

Yes I agree it makes sense!
Le 15 mars 2016 6:52 PM, "Erik Kemperman" [email protected] a
écrit :

Sorry to comment on closed issue, but I was thinking that since the war is
now exclusively dev or prod, the prod one really shouldn't require an
additional argument... Having said that, I have not yet thought of a clean
way to implement this, but first wanted to ask if anyone agrees this makes
sense?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3154#issuecomment-196946319

[notflorian]

Yes, very good idea!

[deepu105]

For dev purpose its just easier to just run mvn/gradlew and start in dev
without passing anything so that behaviour shouldn't change. But in case of
a war file it would be more for prod by default so if there is a way to set
prod as default profile when running as a war then that should be ok
On 16 Mar 2016 03:11, "Florian Fauvarque" [email protected] wrote:

Yes, very good idea!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3154#issuecomment-196978661

[erikkemperman]

I was thinking to set the maven/gradle profile used when building the war as default spring profile when running it.

But I haven't figured out a nice way to do this yet. I tried to use the spring.profiles.default property for this (and leave profiles.active empty) but that doesn't work because application-<profile>.yml is not loaded.

Will try again this evening.

[jdubois]

Be careful if you do this: it also mean we need to stop generating Docker and Docker Compose file for dev, as they use a packaged WAR file.

• So if we remove the "dev" packaging we must also remove the "dev" Docker configuration -> please also remove it in your commit, it's the app.dev.yml and db.dev.yml files in teh src/main/docker folder, and there's probably not much else to do.
• We also need to think if this can be annoying to some people -> I don't think it is, I don't see why you would build a "dev" Docker image, only the "prod" one is interesting. It's the same thing as the WAR file, in fact.