BeanRegistrar that is BeanFactoryAware fails in native image

[dsyer]

The BeanFactory is not injected (but it is when you run the app in JVM with or without AOT processing).

[sdeleuze]

The current BeanRegistrar SPI lacks of some capabilities, but we would like to support them without implementing Aware interface for various reasons, the most important one being that it is too easy to shoot yourself in the foot with BeanFactory as most bean retrieval methods should not be invoked in BeanRegistrar#register .

As a consequence, I am superseding this issue with #34562 which will remove support for Aware interfaces in BeanRegistrar for non AOT mode to get a consistent behavior.

@dsyer I am interested into learning more about the use cases you have for using a BeanFactory in a BeanRegistrar implementation in order to potentially provide such capability in a different way, maybe via additional BeanRegistrar methods. See #21497 related issue that targets providing additional programmatic conditions.

[dsyer]

I was just using it to keep track of which beans were registered during the callback phase in the registry. I wasn't going to call getBean() - that would be stupid. Don't you think we can trust users not to be that stupid?

[sdeleuze]

The thing is that not very implementer of BeanRegistrar will have your expertise, and those implementers could arguably expect they can invoke supported SPIs without shooting themselves in the foot. If you can share more details or a code sample, I can try to see if we can provide support for your use case with a more focused API if we can identify a common enough use case.

[dsyer]

My code was just a stupid demo. But I can imagine you might want to check if there are already beans of a certain type, or with a certain name, before you do something in the registrar.

[sdeleuze]

I can understand that need, but it is not obvious how we can support that at Spring Framework level in a reliable way due to ordering and lifecyle constraints, and BeanRegistrar should be usable on @Configuration classes annotated with @ConditionalOnBean (disclaimer: I have not tested yet) so maybe that's good enough. In any case, let's continue the discussion in #21497 (comment).

[dsyer]

I'm not sure that would be flexible enough. An API in the registry would be much better IMO - it has to be there because it's half way between the registrar (too coarse grained) and the spec (too late to make the decision).

[sdeleuze]

See #21497 (comment), I target additional methods in BeanRegistry for additional conditional capabilities. Just not sure we can support in a reliable way at Framework level a @ConditionalOnBean equivalent.