Lifecycle of bean instantiation is not the same as regular runtime context

[snicoll]

Our instance supplier is taking care of creating the instance and applying autowiring. However, a traditional bean creation lifecycle is as follows, as far as I understood it:

1. Instance creation
2. Bean post-processing before initialization, typically invoking the Aware interface, see ApplicationContextAwareProcessor
3. PropertyValues injection
4. Bean post-processing after initialization, typically injecting @Autowired-annotated members

Right now, the order is more like 1, 4, 2, 3.

Invoking the aware interface is benign and doesn't involve reflection so we could keep it as is. Adding one post-processor per bean to apply autowiring sounds a bit invasive.

WDYT @jhoeller

[snicoll]

I forgot about @PostConstruct& co so that makes it even more important to handle, see #1048

[snicoll]

A chat with @jhoeller helped me fix the ordering. It's rather 1, 4, 2, 3. Because PropertyValues come last and are handled outside of the instance supplier, we may got a chance to get away with the current arrangement.

[snicoll]

We've started to register BeanPostProcessor when it makes sense and we shoud extent that to match framework's ordering. To summarize, it is:

1. Instance creation
2. Autowired injection
3. Property Values
4. Aware callbacks (incuding ImportAware)
5. PostConstruct & co

It looks like moving the import aware callback in a BPP is all that we need at this point.

[snicoll]

Closed by c603e0c