Spring Different order of invocations for ImportAware and EmbeddedValueResolverAware with AOT-optimized contexts

If a configuration class implements ImportAware and EmbeddedValueResolverAware, the setEmbeddedValueResolver method is invoked first, and then setImportMetadata is second.

When the application is compiled to native or running in AOT mode, the order of the method invocation switches, causing the setImportMetadata to be invoked first.

This is causing some problems here in Spring Session

Sample https://github.com/marcusdacoregio/embedded-value-resolver-aware-native

When running in the JVM:

2022-08-02T11:09:00.042-03:00  INFO 94512 --- [           main] com.example.MyConfig                     : Setting resolver org.springframework.beans.factory.config.EmbeddedValueResolver@7a138fc5
2022-08-02T11:09:00.043-03:00  INFO 94512 --- [           main] com.example.MyConfig                     : Setting import metadata org.springframework.beans.factory.config.EmbeddedValueResolver@7a138fc5

When running native or AOT-optimized (notice that resolver is null):

2022-08-02T11:07:41.389-03:00  INFO 94483 --- [           main] com.example.MyConfig                     : Setting import metadata null
2022-08-02T11:07:41.389-03:00  INFO 94483 --- [           main] com.example.MyConfig                     : Setting resolver org.springframework.beans.factory.config.EmbeddedValueResolver@68d0f8c8

Comment From: snicoll

Does the JVM bits you've shared above is running with AOT optimizations? I'd like to understand if the order is due to native strictly or if it can reproduced on the JVM with AOT optimizations.

Comment From: snicoll

Answering to self, I can reproduce the problem with AOT on the JVM so it isn't native specific. I've updated the title accordingly.

Comment From: snicoll

OK I figured it out. Both pieces share the same callback BeanPostProcessor#postProcessBeforeInitialization. However, the import aware callback is added as a bean definition for the regular case and using .addBeanPostProcessor for the AOT case. Adding it directly means that none of the ordering applies. It should be possible to restore the regular order by adding the import aware processor as a bean.

Comment From: snicoll

The order is restored. Thank you very much for the report and the sample @marcusdacoregio!

Comment From: snicoll

That custom code broke the native use case as it's using reflection without a hint.

Comment From: snicoll

This was fixed in 3a890033b78d