Document that active profiles are set at build time with AOT

[luooyii]

I'm not sure if this is a bug.

I am using Spring Boot 3.2.3 and GraalVM CE 21.
Here are the context in application.yaml and yaml files under resources folder.

spring:
  profiles:
    active: local

If I startup the service jar file with cmd "java -jar app.jar --spring.profiles.active=cluster". Activation item will be overridden and only one profile is actived. Here is the spring output log.
2024-03-21 01:01:23.325 [main][0;39m - The following 1 profile is active: "cluster"

But if I use graalvm native image to compile the service and startup AOT package with the same param, just like "./app --spring.profiles.active=cluster". Both "local" and "cluster" will be activated. Here is the spring output.
2024-03-26 15:29:23.448 [main][0;39m - The following 2 profiles are active: "cluster", "local"

[scottfrederick]

Unfortunately, there is not enough information for us to know what's going on. If you would like us to spend some time investigating, please provide a complete minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it and attaching it to this issue.

[luooyii]

Unfortunately, there is not enough information for us to know what's going on. If you would like us to spend some time investigating, please provide a complete minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it and attaching it to this issue.

Thanks for your reply. Here is the minimal sample https://github.com/luooyii/BugDemo
Reproduce steps:

1. Clone the code
2. Run cmd 'mvn clean package'
3. cd target
4. Run cmd '.\native.exe --spring.profiles.active=cluster'
5. You can see output, the new param is accepted but the default value is not overwritten. And if we run the app using jar file with the same param, only "cluster" will be activated.
   

[mhalbritter]

I think this is because of #30421.

[bclozel]

As mentioned by Moritz, this is by design. I haven’t seen a specific mention of that in our AOT reference docs so let’s turn this into a documentation isssue.

[luooyii]

As mentioned by Moritz, this is by design. I haven’t seen a specific mention of that in our AOT reference docs so let’s turn this into a documentation isssue.

Thanks all for your answers. But I think it would be a better way that the AOT compilation product can be consistent with the behavior of jar packages. I use this way to make the AOT compilation package not activate any configurations, and I'm curious if this should be a default configuration when native compilation is enabled.
Because I think this is a very common scenario where some of our default configurations at development time may pollute the deployment environment.

[snicoll]

This is a Maven usage question that you should rather ask on StackOverflow. I don't know what that ** is supposed to achieve but if you want that to apply to AOT you need to put that in the configuration of the execution rather than at the plugin level (as it will apply to every goal).

The whole point is that AOT must be configured to match your target environment, so it's not about dev polluting anything.

[luooyii]

This is a Maven usage question that you should rather ask on StackOverflow. I don't know what that ** is supposed to achieve but if you want that to apply to AOT you need to put that in the configuration of the execution rather than at the plugin level (as it will apply to every goal).

The whole point is that AOT must be configured to match your target environment, so it's not about dev polluting anything.

It isn't a maven usage question. The problem is the inconsistent startup behavior of the AOT compilation and the jar package. I had to modify maven config to get the behavior consistent.

This reply describes the problem in detail.

[snicoll]

I understood your problem and I still think this is a Maven usage question. AOT is processing your app at build time with the goal of preparing for your target environment (that's probably your "cluster" profile). Not doing anything means that you let all the default apply. If you have a default profile that's development only, it's your choice and it will be enabled.

You should rather configure the process-aot goal to enable the cluster profile since that's the profile that represents your target. Once you've done that, you can start the app without specifying any profile since that has been captured by AOT, and that's what this very issue is meant to document.

Another reason this is a maven usage question is that the profiles shouldn't be set the way you did. If you run mvn spring-boot:run locally it will disable your default profile, which is not what you want.

[luooyii]

I understood your problem and I still think this is a Maven usage question. AOT is processing your app at build time with the goal of preparing for your target environment (that's probably your "cluster" profile). Not doing anything means that you let all the default apply. If you have a default profile that's development only, it's your choice and it will be enabled.

You should rather configure the process-aot goal to enable the cluster profile since that's the profile that represents your target. Once you've done that, you can start the app without specifying any profile since that has been captured by AOT, and that's what this very issue is meant to document.

Another reason this is a maven usage question is that the profiles shouldn't be set the way you did. If you run mvn spring-boot:run locally it will disable your default profile, which is not what you want.

Okay, I got your point.
My scenario is that all properties item do not affect spring bean instance. But some required properties are injected from system env when it is deploied. If I active "cluster" when compile, it will throw the error 'Could not resolve placeholder'.
That a big difference when use AOT, and I did not find any explanation from documents. That's why I raise the issue.
Thank you all for your explanation.