Mixing
jHipster App crashes propably because CloudFoundry activates cloud profile
The deployment of my small jhipster App "customerapp" fails and it is probably because cloud foundry sets the profile "cloud" in addition to the profile "dev". I am using several spaces in cloud foundry for the different stages of the development: dev, staging and prod.
I used the jhipster generator, added some entities customer, address and contacts. App is running locally without any issues.
I also use gitlab-ci to build, test and deploy my software. My .gitlab-ci.yml looks like this (I deleted some unecessary parts).
image: mydockerregistry.xxxxx.de/jutoro/jhipster_test/jhipster-dockerimage
services:
- docker:dind
cache:
key: "$CI_BUILD_REF_NAME"
paths:
- node_modules
- .maven
before_script:
- chmod +x mvnw
- export MAVEN_USER_HOME=`pwd`/.maven
stages:
- build
- package
- deployToCF
mvn-build:
stage: build
only:
- dev
- prod
script:
- npm install
- ./mvnw compile -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -
Dspring.profiles.active=dev
mvn-package-dev:
stage: package
only:
- dev
script:
- npm install
- ./mvnw package -Pdev -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=dev
artifacts:
paths:
- target/*.war
mvn-package-prod:
stage: package
only:
- prod
script:
- npm install
- ./mvnw package -Pprod -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=prod
artifacts:
paths:
- target/*.war
deployToCloudFoundry-dev:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- dev
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
deployToCloudFoundry-prod:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- prod
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
The DOCKERFILE (which is built and added to our docker repository also with gitlab-ci):
# DOCKER-VERSION 1.8.2
FROM openjdk:8
MAINTAINER Robert Zieschang
RUN apt-get install -y curl
# install node.js
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs python g++ build-essential &&
apt-get clean &&
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# install yeoman
RUN npm install -g yo
The deplpoyToCloudFoundry.sh shell script:
cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s ${CI_COMMIT_REF_NAME^^}
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME
My manifest file:
---
applications:
- name: customerapp
memory: 1024M
#buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
path: target/customerapp-0.0.1-SNAPSHOT.war
services:
- postgresql
env:
#SPRING_PROFILES_ACTIVE: dev
#SPRING_PROFILES_DEFAULT: dev
#JAVA_OPTS: -Dspring.profiles.active=dev
The pipeline runs well, the app is packed into the war file and uploaded to cloud foundry as well, but it crashes and I assume it is because somehow cloud foundry still applies the profile 'cloud' and this overrides important configurations from jhipsters 'dev' profile.
[...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055 INFO 8 --- [ main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056 INFO 8 --- [ main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064 INFO 8 --- [ main] com.jutoro.cco.CustomerappApp : The following profiles are active: cloud,dev,swagger
[...]
This later leads to:
2019-01-02T19:03:29.17+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:29.172 ERROR 8 --- [ main] com.jutoro.cco.CustomerappApp : You have misconfigured your application! It should not run with both the 'dev' and 'cloud' profiles at the same time.
[...]
After that cloud foundry stops the app.
2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa
The generated application-dev.yml and bootstrap.yml was just modified in some places:
bootstrap.yml
uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config
name: customerapp
profile: dev # profile(s) of the property source
label: config-dev
application-dev.yml
client:
service-url:
defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/
What did I try to set the dev profile in cf:
- added -Dspring.profiles.active=dev in gitlab-ci.yml in addition to -Pdev
- added SPRING_PROFILES_ACTIVE: dev in the manifest env: section
- added SPRING_PROFILES_DEFAULT: dev in the manifest env: section
- added SPRING_APPLICATION_JSON: {"spring.cloud.dataflow.applicationProperties.stream.spring.profiles.active": "dev"} (as mentioned in https://github.com/spring-cloud/spring-cloud-dataflow/issues/2317)
- added JAVA_OPTS: -Dspring.profiles.active=dev in the manifest env: section (cv env customerapp shows that it was set)
- set the JAVA_OPTS -Dspring.profiles.active=dev with cf set-env and cf restage
Any help is appreciated.
Regards
Robert
jhipster cloudfoundry gitlab-ci
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
add a comment |
The deployment of my small jhipster App "customerapp" fails and it is probably because cloud foundry sets the profile "cloud" in addition to the profile "dev". I am using several spaces in cloud foundry for the different stages of the development: dev, staging and prod.
I used the jhipster generator, added some entities customer, address and contacts. App is running locally without any issues.
I also use gitlab-ci to build, test and deploy my software. My .gitlab-ci.yml looks like this (I deleted some unecessary parts).
image: mydockerregistry.xxxxx.de/jutoro/jhipster_test/jhipster-dockerimage
services:
- docker:dind
cache:
key: "$CI_BUILD_REF_NAME"
paths:
- node_modules
- .maven
before_script:
- chmod +x mvnw
- export MAVEN_USER_HOME=`pwd`/.maven
stages:
- build
- package
- deployToCF
mvn-build:
stage: build
only:
- dev
- prod
script:
- npm install
- ./mvnw compile -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -
Dspring.profiles.active=dev
mvn-package-dev:
stage: package
only:
- dev
script:
- npm install
- ./mvnw package -Pdev -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=dev
artifacts:
paths:
- target/*.war
mvn-package-prod:
stage: package
only:
- prod
script:
- npm install
- ./mvnw package -Pprod -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=prod
artifacts:
paths:
- target/*.war
deployToCloudFoundry-dev:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- dev
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
deployToCloudFoundry-prod:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- prod
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
The DOCKERFILE (which is built and added to our docker repository also with gitlab-ci):
# DOCKER-VERSION 1.8.2
FROM openjdk:8
MAINTAINER Robert Zieschang
RUN apt-get install -y curl
# install node.js
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs python g++ build-essential &&
apt-get clean &&
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# install yeoman
RUN npm install -g yo
The deplpoyToCloudFoundry.sh shell script:
cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s ${CI_COMMIT_REF_NAME^^}
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME
My manifest file:
---
applications:
- name: customerapp
memory: 1024M
#buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
path: target/customerapp-0.0.1-SNAPSHOT.war
services:
- postgresql
env:
#SPRING_PROFILES_ACTIVE: dev
#SPRING_PROFILES_DEFAULT: dev
#JAVA_OPTS: -Dspring.profiles.active=dev
The pipeline runs well, the app is packed into the war file and uploaded to cloud foundry as well, but it crashes and I assume it is because somehow cloud foundry still applies the profile 'cloud' and this overrides important configurations from jhipsters 'dev' profile.
[...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055 INFO 8 --- [ main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056 INFO 8 --- [ main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064 INFO 8 --- [ main] com.jutoro.cco.CustomerappApp : The following profiles are active: cloud,dev,swagger
[...]
This later leads to:
2019-01-02T19:03:29.17+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:29.172 ERROR 8 --- [ main] com.jutoro.cco.CustomerappApp : You have misconfigured your application! It should not run with both the 'dev' and 'cloud' profiles at the same time.
[...]
After that cloud foundry stops the app.
2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa
The generated application-dev.yml and bootstrap.yml was just modified in some places:
bootstrap.yml
uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config
name: customerapp
profile: dev # profile(s) of the property source
label: config-dev
application-dev.yml
client:
service-url:
defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/
What did I try to set the dev profile in cf:
- added -Dspring.profiles.active=dev in gitlab-ci.yml in addition to -Pdev
- added SPRING_PROFILES_ACTIVE: dev in the manifest env: section
- added SPRING_PROFILES_DEFAULT: dev in the manifest env: section
- added SPRING_APPLICATION_JSON: {"spring.cloud.dataflow.applicationProperties.stream.spring.profiles.active": "dev"} (as mentioned in https://github.com/spring-cloud/spring-cloud-dataflow/issues/2317)
- added JAVA_OPTS: -Dspring.profiles.active=dev in the manifest env: section (cv env customerapp shows that it was set)
- set the JAVA_OPTS -Dspring.profiles.active=dev with cf set-env and cf restage
Any help is appreciated.
Regards
Robert
jhipster cloudfoundry gitlab-ci
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
You can setJBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.
– Daniel Mikusa
Jan 3 at 17:43
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12
add a comment |
The deployment of my small jhipster App "customerapp" fails and it is probably because cloud foundry sets the profile "cloud" in addition to the profile "dev". I am using several spaces in cloud foundry for the different stages of the development: dev, staging and prod.
I used the jhipster generator, added some entities customer, address and contacts. App is running locally without any issues.
I also use gitlab-ci to build, test and deploy my software. My .gitlab-ci.yml looks like this (I deleted some unecessary parts).
image: mydockerregistry.xxxxx.de/jutoro/jhipster_test/jhipster-dockerimage
services:
- docker:dind
cache:
key: "$CI_BUILD_REF_NAME"
paths:
- node_modules
- .maven
before_script:
- chmod +x mvnw
- export MAVEN_USER_HOME=`pwd`/.maven
stages:
- build
- package
- deployToCF
mvn-build:
stage: build
only:
- dev
- prod
script:
- npm install
- ./mvnw compile -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -
Dspring.profiles.active=dev
mvn-package-dev:
stage: package
only:
- dev
script:
- npm install
- ./mvnw package -Pdev -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=dev
artifacts:
paths:
- target/*.war
mvn-package-prod:
stage: package
only:
- prod
script:
- npm install
- ./mvnw package -Pprod -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=prod
artifacts:
paths:
- target/*.war
deployToCloudFoundry-dev:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- dev
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
deployToCloudFoundry-prod:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- prod
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
The DOCKERFILE (which is built and added to our docker repository also with gitlab-ci):
# DOCKER-VERSION 1.8.2
FROM openjdk:8
MAINTAINER Robert Zieschang
RUN apt-get install -y curl
# install node.js
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs python g++ build-essential &&
apt-get clean &&
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# install yeoman
RUN npm install -g yo
The deplpoyToCloudFoundry.sh shell script:
cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s ${CI_COMMIT_REF_NAME^^}
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME
My manifest file:
---
applications:
- name: customerapp
memory: 1024M
#buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
path: target/customerapp-0.0.1-SNAPSHOT.war
services:
- postgresql
env:
#SPRING_PROFILES_ACTIVE: dev
#SPRING_PROFILES_DEFAULT: dev
#JAVA_OPTS: -Dspring.profiles.active=dev
The pipeline runs well, the app is packed into the war file and uploaded to cloud foundry as well, but it crashes and I assume it is because somehow cloud foundry still applies the profile 'cloud' and this overrides important configurations from jhipsters 'dev' profile.
[...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055 INFO 8 --- [ main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056 INFO 8 --- [ main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064 INFO 8 --- [ main] com.jutoro.cco.CustomerappApp : The following profiles are active: cloud,dev,swagger
[...]
This later leads to:
2019-01-02T19:03:29.17+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:29.172 ERROR 8 --- [ main] com.jutoro.cco.CustomerappApp : You have misconfigured your application! It should not run with both the 'dev' and 'cloud' profiles at the same time.
[...]
After that cloud foundry stops the app.
2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa
The generated application-dev.yml and bootstrap.yml was just modified in some places:
bootstrap.yml
uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config
name: customerapp
profile: dev # profile(s) of the property source
label: config-dev
application-dev.yml
client:
service-url:
defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/
What did I try to set the dev profile in cf:
- added -Dspring.profiles.active=dev in gitlab-ci.yml in addition to -Pdev
- added SPRING_PROFILES_ACTIVE: dev in the manifest env: section
- added SPRING_PROFILES_DEFAULT: dev in the manifest env: section
- added SPRING_APPLICATION_JSON: {"spring.cloud.dataflow.applicationProperties.stream.spring.profiles.active": "dev"} (as mentioned in https://github.com/spring-cloud/spring-cloud-dataflow/issues/2317)
- added JAVA_OPTS: -Dspring.profiles.active=dev in the manifest env: section (cv env customerapp shows that it was set)
- set the JAVA_OPTS -Dspring.profiles.active=dev with cf set-env and cf restage
Any help is appreciated.
Regards
Robert
jhipster cloudfoundry gitlab-ci
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
The deployment of my small jhipster App "customerapp" fails and it is probably because cloud foundry sets the profile "cloud" in addition to the profile "dev". I am using several spaces in cloud foundry for the different stages of the development: dev, staging and prod.
I used the jhipster generator, added some entities customer, address and contacts. App is running locally without any issues.
I also use gitlab-ci to build, test and deploy my software. My .gitlab-ci.yml looks like this (I deleted some unecessary parts).
image: mydockerregistry.xxxxx.de/jutoro/jhipster_test/jhipster-dockerimage
services:
- docker:dind
cache:
key: "$CI_BUILD_REF_NAME"
paths:
- node_modules
- .maven
before_script:
- chmod +x mvnw
- export MAVEN_USER_HOME=`pwd`/.maven
stages:
- build
- package
- deployToCF
mvn-build:
stage: build
only:
- dev
- prod
script:
- npm install
- ./mvnw compile -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -
Dspring.profiles.active=dev
mvn-package-dev:
stage: package
only:
- dev
script:
- npm install
- ./mvnw package -Pdev -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=dev
artifacts:
paths:
- target/*.war
mvn-package-prod:
stage: package
only:
- prod
script:
- npm install
- ./mvnw package -Pprod -DskipTests -Dmaven.repo.local=$MAVEN_USER_HOME -Dspring.profiles.active=prod
artifacts:
paths:
- target/*.war
deployToCloudFoundry-dev:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- dev
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
deployToCloudFoundry-prod:
image: pivotalpa/cf-cli-resource
stage: deployToCF
only:
- prod
cache:
paths:
- bin/
script:
- bash ci/scripts/deployToCloudFoundry.sh
The DOCKERFILE (which is built and added to our docker repository also with gitlab-ci):
# DOCKER-VERSION 1.8.2
FROM openjdk:8
MAINTAINER Robert Zieschang
RUN apt-get install -y curl
# install node.js
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs python g++ build-essential &&
apt-get clean &&
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# install yeoman
RUN npm install -g yo
The deplpoyToCloudFoundry.sh shell script:
cf login -a $CF_API_ENDPOINT -u $CF_USER -p $CF_PASS -o "${CF_ORG^^}" -s ${CI_COMMIT_REF_NAME^^}
cf push -n $CI_PROJECT_NAME-$CI_COMMIT_REF_NAME
My manifest file:
---
applications:
- name: customerapp
memory: 1024M
#buildpack: https://github.com/cloudfoundry/java-buildpack#v3.19.2
path: target/customerapp-0.0.1-SNAPSHOT.war
services:
- postgresql
env:
#SPRING_PROFILES_ACTIVE: dev
#SPRING_PROFILES_DEFAULT: dev
#JAVA_OPTS: -Dspring.profiles.active=dev
The pipeline runs well, the app is packed into the war file and uploaded to cloud foundry as well, but it crashes and I assume it is because somehow cloud foundry still applies the profile 'cloud' and this overrides important configurations from jhipsters 'dev' profile.
[...]
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.055 INFO 8 --- [ main] pertySourceApplicationContextInitializer : 'cloud' property source added
2019-01-02T19:03:16.05+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.056 INFO 8 --- [ main] nfigurationApplicationContextInitializer : Reconfiguration enabled
2019-01-02T19:03:16.06+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:16.064 INFO 8 --- [ main] com.jutoro.cco.CustomerappApp : The following profiles are active: cloud,dev,swagger
[...]
This later leads to:
2019-01-02T19:03:29.17+0100 [APP/PROC/WEB/0] OUT 2019-01-02 18:03:29.172 ERROR 8 --- [ main] com.jutoro.cco.CustomerappApp : You have misconfigured your application! It should not run with both the 'dev' and 'cloud' profiles at the same time.
[...]
After that cloud foundry stops the app.
2019-01-02T19:04:11.09+0100 [CELL/0] OUT Cell 83899f60-78c9-4323-8d3c-e6255086c8a7 stopping instance 74be1834-b656-4445-506c-bdfa
The generated application-dev.yml and bootstrap.yml was just modified in some places:
bootstrap.yml
uri: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/config
name: customerapp
profile: dev # profile(s) of the property source
label: config-dev
application-dev.yml
client:
service-url:
defaultZone: https://admin:${jhipster.registry.password}@url.tomy.jhipsterregistryapp/eureka/
What did I try to set the dev profile in cf:
- added -Dspring.profiles.active=dev in gitlab-ci.yml in addition to -Pdev
- added SPRING_PROFILES_ACTIVE: dev in the manifest env: section
- added SPRING_PROFILES_DEFAULT: dev in the manifest env: section
- added SPRING_APPLICATION_JSON: {"spring.cloud.dataflow.applicationProperties.stream.spring.profiles.active": "dev"} (as mentioned in https://github.com/spring-cloud/spring-cloud-dataflow/issues/2317)
- added JAVA_OPTS: -Dspring.profiles.active=dev in the manifest env: section (cv env customerapp shows that it was set)
- set the JAVA_OPTS -Dspring.profiles.active=dev with cf set-env and cf restage
Any help is appreciated.
Regards
Robert
jhipster cloudfoundry gitlab-ci
jhipster cloudfoundry gitlab-ci
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
asked Jan 2 at 18:51
Robert ZieschangRobert Zieschang
115
115
You can setJBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.
– Daniel Mikusa
Jan 3 at 17:43
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12
add a comment |
You can setJBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.
– Daniel Mikusa
Jan 3 at 17:43
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12
You can set
JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]' to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.– Daniel Mikusa
Jan 3 at 17:43
You can set
JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]' to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.– Daniel Mikusa
Jan 3 at 17:43
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12
add a comment |
2 Answers
2
active
oldest
votes
Forget the answer before. Turns out deep down it was a datasource problem which made the app not respond to the heartbeats.
Uncomment
#hibernate.connection.provider_disables_autocommit: true
In the application properties fixed this.
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
add a comment |
Maybe any "future" person may stumble upon the same behaviour.
I was able to deploy my jhipster app to cloud foundry.
I somehow "fixed" it, but I am not aware of further consequences. Yet.
Turned out cloud foundry had a problem to monitor my jhipster app via the standard health-check-type http which should be "heartbeat"?
So I decided to switch the monitoring behaviour to a not heartbeat-ish way.
Just switch health-check-type to process in your manifest.yml file.
health-check-type: process
The app is now running.
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
|
show 4 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011648%2fjhipster-app-crashes-propably-because-cloudfoundry-activates-cloud-profile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Forget the answer before. Turns out deep down it was a datasource problem which made the app not respond to the heartbeats.
Uncomment
#hibernate.connection.provider_disables_autocommit: true
In the application properties fixed this.
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
add a comment |
Forget the answer before. Turns out deep down it was a datasource problem which made the app not respond to the heartbeats.
Uncomment
#hibernate.connection.provider_disables_autocommit: true
In the application properties fixed this.
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
add a comment |
Forget the answer before. Turns out deep down it was a datasource problem which made the app not respond to the heartbeats.
Uncomment
#hibernate.connection.provider_disables_autocommit: true
In the application properties fixed this.
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
Forget the answer before. Turns out deep down it was a datasource problem which made the app not respond to the heartbeats.
Uncomment
#hibernate.connection.provider_disables_autocommit: true
In the application properties fixed this.
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
answered Jan 30 at 16:47
Robert ZieschangRobert Zieschang
115
115
add a comment |
add a comment |
Maybe any "future" person may stumble upon the same behaviour.
I was able to deploy my jhipster app to cloud foundry.
I somehow "fixed" it, but I am not aware of further consequences. Yet.
Turned out cloud foundry had a problem to monitor my jhipster app via the standard health-check-type http which should be "heartbeat"?
So I decided to switch the monitoring behaviour to a not heartbeat-ish way.
Just switch health-check-type to process in your manifest.yml file.
health-check-type: process
The app is now running.
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
|
show 4 more comments
Maybe any "future" person may stumble upon the same behaviour.
I was able to deploy my jhipster app to cloud foundry.
I somehow "fixed" it, but I am not aware of further consequences. Yet.
Turned out cloud foundry had a problem to monitor my jhipster app via the standard health-check-type http which should be "heartbeat"?
So I decided to switch the monitoring behaviour to a not heartbeat-ish way.
Just switch health-check-type to process in your manifest.yml file.
health-check-type: process
The app is now running.
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
|
show 4 more comments
Maybe any "future" person may stumble upon the same behaviour.
I was able to deploy my jhipster app to cloud foundry.
I somehow "fixed" it, but I am not aware of further consequences. Yet.
Turned out cloud foundry had a problem to monitor my jhipster app via the standard health-check-type http which should be "heartbeat"?
So I decided to switch the monitoring behaviour to a not heartbeat-ish way.
Just switch health-check-type to process in your manifest.yml file.
health-check-type: process
The app is now running.
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
Maybe any "future" person may stumble upon the same behaviour.
I was able to deploy my jhipster app to cloud foundry.
I somehow "fixed" it, but I am not aware of further consequences. Yet.
Turned out cloud foundry had a problem to monitor my jhipster app via the standard health-check-type http which should be "heartbeat"?
So I decided to switch the monitoring behaviour to a not heartbeat-ish way.
Just switch health-check-type to process in your manifest.yml file.
health-check-type: process
The app is now running.
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
answered Jan 10 at 8:35
Robert ZieschangRobert Zieschang
115
115
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
|
show 4 more comments
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
The drawback of this is that CF won't be able to detect if your application stops working and restart it. With a health check type of "process", all CF looks at is if the process is up and running. As long as the JVM doesn't exit, this will be true. If your app were to hang and stop processing requests, the process would continue running and your app would not be automatically restarted by the platform. If you set health-check-type to "http", the platform will attempt to access an HTTP endpoint from your app (default "/"). If this returns anything but 200 OK, app is restarted automatically.
– Daniel Mikusa
Jan 11 at 18:16
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Thanks Daniel Mikusa for the clarification. This is not the desired behaviour. So I'll give it a try to turn off auto configuration. Thank you so far.
– Robert Zieschang
Jan 14 at 7:35
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Hello Daniel, I removed the health-check-type, added the JBP_CONFIG_SPRING_AUTO_RECONFIGURATION... The app starts now but nevertheless, the cloud profile is still applied. 2019-01-14T09:32:24.93+0100 [APP/PROC/WEB/0] OUT Profile(s): [cloud, dev, swagger]
– Robert Zieschang
Jan 14 at 8:41
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
Where/how did you add that? Can you confirm from the output of staging that Auto reconfiguration is not still being installed? When it's installed, you'll see a line from the JBP during staging that specifically says it's installed. I would suggest toggling the change you made on/off and confirming that it's actually disabling auto reconfiguration. Let me know if it's disabled and you're still seeing the cloud profile on.
– Daniel Mikusa
Jan 14 at 16:39
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
My bad. I added it to the env variables. Now autoconfiguration is deactivated. This means my ${vcap. } placeholders for my datasource won't work, right?
– Robert Zieschang
Jan 15 at 9:49
|
show 4 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011648%2fjhipster-app-crashes-propably-because-cloudfoundry-activates-cloud-profile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You can set
JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '[enabled: false]'to tell the JBP to disable spring auto reconfiguration, which is what adds the cloud profile. Just be careful as that also disable the auto reconfiguration of services.– Daniel Mikusa
Jan 3 at 17:43
Thank you @DanielMikusa but I do not exactly know, which consequences would lay ahead, if I turn off the autoconfiguration. But I found a way to deploy. Thank you for your hint.
– Robert Zieschang
Jan 10 at 8:36
It depends on your app. For example, you have a single DataSource you can configure it to work locally. Then when you push to CF, the JBP's autoreconfiguration will automagically reconfigure your single DataSource to point to the bound database. It's a little bit magical and has some limitations, so IMO it's better to just use Spring Cloud Connectors directly and explicitly configure your DataSources. If you do that, then disabling autoreconfiguration doesn't really have any impact.
– Daniel Mikusa
Jan 11 at 18:12