Possible Bug: What is the consistent approach to load/apply or not the active profiles from the application.properties file?

[manueljordan]

For

Spring Tool Suite 4 

Version: 4.17.2.RELEASE
Build Id: 202301310704
Revision: 4c43862ec9482cb5c289960e5514998e59d2f1fe

For a Spring Boot project created through https://start.spring.io/ as:

• with some Starter Dependencies
• named as spring-boot-project-a
• based on Maven

If is accomplished the following:

• unzipped
• imported into the IDE.
• Added some custom beans @Bean, @Service .... etc
• The application.properties file is edited with spring.profiles.active=h2,cache,exception-non

Scenario Alpha

If the app is executed - as the first time - through:

• spring-boot-project-a -> Right Click -> Run As -> Spring Boot App

The app fails at startup because the active profiles defined through the spring.profiles.active property in the application.properties file were not applied and many @Autowired failed due missing dependencies because they were not created due the missing activation of the profiles.

The solution is arrive through:

• Top Menu -> Run -> Run Configurations... -> Spring Boot App -> spring-boot-project-a - SpringBoot...Application

And apply one of the two possible following options within the current dialog window opened according with the previous step:

• Spring Boot tab -> Profile text field: h2,cache,exception-non -> Apply button -> Run button
• Arguments tab -> VM arguments: text area: add below of the current value -Dspring.profiles.active=h2,cache,exception-non -> Apply button -> Run button

Therefore through either Spring Boot or Arguments tab the app runs in peace because now the active profiles were applied.

Question 1

• Why was not considered from the beginning the application.properties file which contains the active profiles through spring.profiles.active?

Scenario Beta

Once fixed (or applied Scenario Alpha) if later the app is executed through:

• Boot Dashboard view -> Select the spring-boot-project-a project -> Execute (Re)start as either Top Menu of the view itself or right click

The app works as expected and here exists the obvious assumption that the Boot Dashboard view reused the spring-boot-project-a - SpringBoot...Application defined on Spring Boot App with the current settings defined through either Spring Boot or Arguments tab but...

The Boot Dashboard view is not really reusing the spring-boot-project-a - SpringBoot...Application with the current settings where the active profiles was defined. So, is really using the application.properties file.

• How did I get the conclusion about that really the application.properties file is used?

Well, through the Boot Dashboard view was executed the spring-boot-project-b project - other project created and imported in the same way as the first spring-boot-project-a project - where it has its own application.properties file with its own spring.profiles.active property and of course its own Beans - and it worked without any problem.

And yes, at Run Configurations -> Spring Boot App was created spring-boot-project-b - SpringBoot...Application, it because it was the first execution. Furthermore was confirmed that the Spring Boot and Arguments tabs does not have editions/declaration about the active profiles

Therefore assuming that:

• Boot Dashboard view -> spring-boot-project-b -> (Re)start
• Top Menu -> Run -> Run History -> spring-boot-project-b -> SpringBoot...Application

Are both the same and the former executes behind the scene the latter, therefore was expected an error at startup as Scenario Alpha due the missing profiles. But I did not happen.

Question 2

• Why now was considered from the beginning the application.properties file which contains the active profiles through spring.profiles.active?

Scenario Delta

If spring-boot-project-a - SpringBoot...Application and spring-boot-project-b - SpringBoot...Application are deleted from Spring Boot App of the Run Configurations dialog window and then spring-boot-project-a - SpringBoot...Application is re-created again through:

• spring-boot-project-a -> Right Click -> Run As -> Spring Boot App

The expected error at startup as Scenario Alpha due the missing profiles - it because the Spring Boot and Arguments tabs does not have editions/declaration about the active profiles due the re-creation - did not happen!!!

Question 3

• Why now the app is running if the profiles were not explicitly declared?

From the Beginning...

Even more, if the spring-boot-project-a project is deleted and imported as from the beginning therefore Scenario Alpha happens again... it is interesting ...

Reason of this Post

• What is the consistent approach to load/apply or not the active profiles from the application.properties file?

[BoykoAlex]

Once you edit application.properties try to perform Project -> Clean on your project (assuming Build Automatically is on for you).
There is a bug in m2e (maven tools for eclipse) that results in application.properties and other resource files not being copied into the target folder and hence running application might be missing this file which would explain missing profile settings. (See #929 and eclipse-m2e/m2e-core#1302 (comment))
Looking at the STS version you're using you might be experiencing the original profound m2e issue that was there at the beginning and got mostly fixed. Therefore, I'd look into trying the latest STS distro.

[manueljordan]

Thanks for the reply. In 2 weeks I should do this upgrade and return the respective feedback, it because right now I am with a project on hands and I want have all stable and running as so far. Thanks for your understanding

[manueljordan]

Hello

(assuming Build Automatically is on for you)

No, I don't use that, normally I use the terminal with some scripts to execute for example the mvn clean compile and mvn spring-boot:run commands - and to be honest only for academic purposes I use m2e to accomplish/use the same goals as command, it because the items added at Run Configurations become overflowed - BTW when The project uses Spring Boot Dev Tools is mandatory use Build Automatically, if is used either m2e or mvn all the app crushes... it seems it breaks one or the two ClassLoaders cached and handled by Dev Tools - of course it is other history ...

Therefore, I'd look into trying the latest STS distro

This weekend should be tested. Let me know if there is a beta version to test it (if is the case) otherwise I am going to use the latest release

Thanks for your understanding

[BoykoAlex]

Okay, I see, then run your build with mvn clean compile oe mvn clean package but then if you launch your project via STS (i.e. Boot Dashboard) either right-click on the project in Package Explorer and clik on "Refresh" menu item or enable automatic workspace refresh on external file changes (I think preference page "General" -> "Workspace" check-mark "Refresh Using Native Hooks or Polling").
The issue is files are modified externally and until they are refreshed in Eclipse it won't know they are updated.

[manueljordan]

I think is better try with the same approach applied, only with the IDE, first with m2e and later with the Boot Dashboard view . Otherwise I am not able to confirm if the bug was fixed or not. BTW. According with the 2nd link shared the situation was fixed. I hope this latest STS release works in peace :)

(I think preference page "General" -> "Workspace" check-mark "Refresh Using Native Hooks or Polling").

Yes, I already have that option enabled.

The issue is files are modified externally and until they are refreshed in Eclipse it won't know they are updated.

Agree, that's why I have the Refresh Using Native Hooks or Polling enabled as default. To avoid synchronization problems ...

[manueljordan]

For the 4.19.1.RELEASE the bug situation does not happen anymore.

[martinlippert]

For the 4.19.1.RELEASE the bug situation does not happen anymore.

Looks like we forgot to close this issue here, doing that now. Thanks for the feedback and glad to hear that this is working since the 4.19.1.RELEASE