Set up "YAML Config Integration" milestone & group any relevant issues together

[Damian-R-Smith]

Reviewing some of the other issues here I see a few around using yml files for configs etc. which I think would add decent value to the application. There was other things I would like to have myself so I figured the best thing would be to gather everything under a single "parent feature" (milestone?) to discuss what's needed and add related issues.

I have a few suggestions for functionality (big one for me is yml profiles, list all/select when running instance etc etc) that would be good to have as part of this but I'll wait to see what everyone thinks before opening 10 new issues for everything 😄

• use actuator prefix from application.yml #23 use actuator prefix from application.yml

• use spring boot port from application.yml/boostrap.yml #22 use port from application.yml

[ErnestOrt]

No worries Damian, open as many ideas you could have... it's free!!

Are all welcome!

:)

[ErnestOrt]

Appreciate your ideas!

To be honest, I have been thinking quite a lot about this feature when @cforce point it out.

I end up thinking this would be an overengineering solution, in other words, to avoid two input fields, we should create an algorithm that will have to find application file (properties or yml), will have to parser them (two parsers) and, moreover, we will have to deal with exceptions (file not found, properties not found).

Personally. sounds too much to avoid couple fields in a form, what do you think?

[cforce]

@ErnestOrt

a.)
If you use the Spring Boot Maven or Gradle plugins to create an executable jar, you can run your application using java -jar, as shown in the following example:
$ java -jar target/myapplication-0.0.1-SNAPSHOT.jar

b.)
The Spring Boot Maven plugin includes a run goal that can be used to quickly compile and run your application. Applications run in an exploded form, as they do in your IDE. The following example shows a typical Maven command to run a Spring Boot application:
$ mvn spring-boot:run
You might also want to use the MAVEN_OPTS operating system environment variable, as shown in the following example:
$ export MAVEN_OPTS=-Xmx1024m

c.)
The Spring Boot Gradle plugin also includes a bootRun task that can be used to run your application in an exploded form. The bootRun task is added whenever you apply the org.springframework.boot and java plugins and is shown in the following example:

$ gradle bootRun
You might also want to use the JAVA_OPTS operating system environment variable, as shown in the following example:
$ export JAVA_OPTS=-Xmx1024m

So from what i see running the app using the application.yml packaked with the jar (instead overwriting it like you do in EcosystemManagerpublic void startInstance(String id, String port, String vmArguments, Integer startingDelay) throws CreatingSettingsFolderException, ReadingEcosystemException, RunningMicroserviceScriptException, SavingEcosystemException, InterruptedException {
log.info("Starting instances id: [{}] port: [{}] vmArguments: [{}] startingDelay: [{}]", id, port, vmArguments, startingDelay);) its the standard way the executable jat shall will launch. If you wanna optional use a different profile you can still do that by passing arg (-Dspring.profiles.active=) or EXPORT/SET SPRING_PROFILES_ACTIVE=

[Damian-R-Smith]

@ErnestOrt Yeah I've been mulling over this in my head trying to figure out a good approach here, and I definitely agree with your points but I do think we should still think about adding config profile support maybe as part of the launch instance? If the profile specific yml isn't found spring reverts back to the defaults in your base application.yml so it's not going to cause any exceptions at that point.

@cforce
man use the code blocks when showing some examples for the sake of our eyes 😄. And the normal way to run spring boot apps is mvn spring-boot:run with your profile set as a vm arg like you say or else in your bootstrap.yml file, but I don't see why you would want to or need to overwrite whatever the user's memory settings are for their machine. If you need to set these do it at the application level not at the environment level.