Refine Spring profile support with AOT/native

[sdeleuze]

Developers of Spring applications on the JVM are typically accustomed to being able to do advanced configuration at runtime with mechanisms like Spring profiles. Ahead-Of-Time transformations and GraalVM native image by design require one to define at build time the various beans. What can and cannot change at runtime is usually not well understood.

This issue is an attempt to clarify the current state of affairs (could materialize as a documentation update in 6.0.x), discuss what could be improved, and what will likely not be supported. What is discussed here will likely require related Spring Boot issue(s) since changes are likely to be required on both Spring Framework and Spring Boot projects, but let's start the discussion here.

I have created this https://github.com/sdeleuze/demo-profile-aot repository to illustrate the behavior of a generated Spring Boot native executable. It is possible at runtime:

• To enable the Spring Boot debug flag with demo-profile-aot --debug
• To customize the log level with demo-profile-aot -Dlogging.level.org.springframework.beans.factory.support.DefaultListableBeanFactory=debug
• To enable a profile that does not impact the beans created with demo-profile-aot -Dspring.profiles.active=local
• You can also customize a configuration property value specifying directly the property value with demo-profile-aot -Dsample.message="Customized message from the command line"
  What you can't do is enabling at runtime a profile that involves changing the bean configuration (for example adding a new bean specific to a profile). See the repository above for more details.

While this limitation can be initially frustrating, I think it makes sense if we take a step back on what the purpose of AOT transformation is and the goal of native application to ship only what is necessary in the native executable. It is important to have in mind that it is recommended to create the native executable (from sources or from the Spring Boot executable JAR) as late as possible in the deployment process, as close as possible to the target server when it will be deployed, usually as a container. In that sense, the generated native executable is not the strict equivalent of the executable JAR: it is CPU architecture specific and has a predefined set of beans. Removing this limitation is technically possible but would involve a huge refactoring of how conditions are evaluated AOT and would probably end up with increased footprint, build time, and executable size since more code would be shipped. I tend to think our time is better spent on other topics.

That said, I am in favor of adding the capability for people to specify the profiles to use with AOT/Native at build time. Once supported on Spring Framework AOT engine, this could translate on Spring Boot side to adding the capability to specify, for example (the way it is specified would be decided by the Spring Boot team):

• With Gradle: gradle nativeCompile -Dspring.profiles.active=prod
• With Maven: mvn -Pnative native:compile -Dspring.profiles.active=prod

This would allow developers to deal for example with different databases (H2 versus PostgreSQL for example) using distinct profiles, with the difference that here this needs to specified Ahead-Of-Time.

I am open to move forward on this proposal in the Spring Framework 6.0.x or 6.1.0 time frame, depending on the feedback from the Spring Boot team and the community.

[bclozel]

I'm also in favor of making it easier to activate a profile for the AOT processing phase. We should discuss how this would translate for the generated code, I guess we should generate a Java statement that adds that profile automatically when the AOT sources are executed otherwise we could end up in an inconsistent state if the profile is somehow not activated at runtime.

Back to the broader topic of @Profile support in AOT/native apps. Our current AOT infrastructure relies on BeanDefinition already parsed and processed and we "write out" those definitions as functional bean registrations. @Profile is implemented as a Condition and this means we need to support all conditions as a result. For example a @ConditionalOnMissingBean condition needs to adapt to the fact that a @Profile annotated configuration class could contribute such a bean, etc.

If we wanted to have dynamic @Profile support at runtime, we would need to:

• execute some Condition instances during the AOT phase (like the classpath detection ones)
• turn other Condition into conditional statements in the AOT generated code.

This feature is not trivial and would require important changes in the AOT and the core container itself. I think this would require #29553 to work.

In general, I think the build configuration flag is a nice first step and I'm still not convinced that we need full profile support; supporting it would mean that the footprint of native images would increase significantly and they would lose one of their security advantages: not shipping code that's not use and protecting against an entire class of attacks. More, I think that in a native world it's expected to ship different binaries for separate target environments. As Java developers we might be used to shipping a single artifact for multiple environments (a JAR) and I think we should keep doing that. As @sdeleuze said, the native compilation phase should be the very last step before deployment and should not be the reference artifact.

[sdeleuze]

Related to that, I think the workflow for source-based deployment is already ok, but it may potentially be interesting to explore first class options to create native executable from a Spring Boot executable JAR that does not contain AOT generated code / metadata.

[sdeleuze]

Notice Spring Framework reference documentation mentions:

@Profile, in particular profile-specific configuration needs to be chosen at build time

I think this is consistent with the refinement proposed in this issue.

[Azbesciak]

Hello,
First of all, thank you for that effort - for the whole spring, and for years of work under that AOT processing. From my experience with Graal - since it started, and now, I know that it may be painful for many reasons (great project anyway :) ) .

To the topic - the important thing for me is to have @ConditionalOnProperty - at least. I got your idea that it would increase the build time, but look - from the other side, If I have multiple customers/need to change parameters depending on some conditions, should I build the image for every option, and maintain it? Not to mention that I can have some configuration changes, did not notice it and see that only on production, after (hopefully) testing the native image (which is unfortunately still not obvious for me, because the flag spring.aot.enabled does not work for me - it runs, whereas the app in the runtime fails somewhere).

AOT exists for years in development - just see JS apps like angular. The purpose, for me, is to remove the dead code, mostly.
The result is still very good.

If something is under the condition, it should not be perceived as a dead code; to say more, the user is rather aware that it can impact the runtime (they want to enable or disable it) - and probably also the build time, and they agree with that (otherwise why they would use that?).

To say more, I could understand that the code was removed if the condition was falsy during the build. But why the bean was still provided when it was truly during the build, and then disabled during the runtime - I do not know.

I suppose also that most of the build time is probably consumed on the lib/framework side code, not the user side - which is mostly under the configuration.

I think it should be provided somehow - with the flag or by default - anyway. Faster or later users would have to provide some workarounds anyway. One of it I see now is to register beans (did not test) in a functional way, just checking (possible) conditions in the runtime. Please, save me that effort, I am already a bit confused during my migration, which already took me 50 hours of watching that something fails (hopefully) during the build, or (most often) in runtime (reflection/jackson mostly). Note that I have only 5 small/medium services, which do not use very complex features, only reactive web/reactive mongo/jackson/redis/security and cloud gateway.

[sdeleuze]

As shown in https://github.com/sdeleuze/demo-profile-aot, based on @snicoll insights I figured out we already support defining Spring profile AOT, it was just not easy to figure out based on the documentation. For the various use cases I have seen, this was the biggest need.

To be discuss with the wider team, but the fact it is support IMO make less critical the need for more advanced AOT profile management, like begin to have a more advancec mechamsim that evaluate some condition at build-time and some other at runtime. This is not trivial, introduce extra complexity and will likely impact the resulting footprint.

If we do something, I tend to think it would have to be explicit (like specifying that a profile or a property could change at runtime so don't remove it AOT), but I am not yet convince it is worth the time we would have spend on this. Maybe we could just make specifying profiles at build time a bit more first class at Boot level.