3

I've just built my Spring project using GraalVM native image like so:

mvn -Pnative -DskipTests clean package

Which gives me a native executable file. When I start it though, it seems like it doesn't have any active profile set. I would like to do something like this:

./my-native-app --spring.profiles.active=production

How can I achieve that?

Andrew Lalis
  • 894
  • 3
  • 15
  • 26

1 Answers1

2

The profiles cannot be activated on runtime. They can be processed only at build time, as we can find in the Spring Native Documentation:

https://docs.spring.io/spring-native/docs/current/reference/htmlsingle/#aot-bean-factory-preparation

"A profile is a special sort of condition so these are also evaluated at build-time. It is recommended to avoid the use of profiles as processing them at build-time does not allow you to enable or disable them at runtime anyway. If you want to keep using them, they should be enabled at build-time, for instance by adding the spring.profiles.active property in application.properties."

user6354846
  • 46
  • 7
  • I don't think this is correct. The profiles are still active - and props from them are consumed. The thing is - that the beans that are going to be included in the context are determined at build time, so if those depend on the profiles/properties - that's where extra attention is needed. For example, the new Spring Boot 3 tracing includes or excludes it's beans based on whether it's enabled in the props. So, if you want tracing when you are in a native image - you could consider adding a prop file for 'build', and activating that during the build. – matthenry87 May 10 '23 at 18:29
  • @matthenry87 is correct. You can utilize run-time profiles so long as the definitions were provided at build-time. A good example of this is with the spring-oauth2-client where the issuer or jwk-set-uri must be set at build-time for spring to correctly locate those components at build time. But those values are override-able at runtime to point to another oauth2 server. – StevenPG Aug 24 '23 at 20:21
  • @StevenPG We deploy the same image to different environments with different Spring profiles and corresponding props with no issues. The prop files are selected and used exactly the same as a normal JVM app. – matthenry87 Aug 25 '23 at 22:42
  • We use different jwk-set-uri with the same image in different environments just fine. The only difference between JVM and native is that the beans that will be in your context are fixed at build time, so if your props control whether a bean will be present or not, that's where you have to add an additional profile to activate during the build. – matthenry87 Aug 25 '23 at 22:45