Spring ConfigurationClassPostProcessor makes assumptions about the presence of an ImportRegistry

In ConfigurationClassPostProcessor:

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
        ...
        if (!this.registriesPostProcessed.contains(factoryId)) {
            // BeanDefinitionRegistryPostProcessor hook apparently not supported...
            // Simply call processConfigurationClasses lazily at this point then.
            processConfigBeanDefinitions((BeanDefinitionRegistry) beanFactory);
        }
        enhanceConfigurationClasses(beanFactory);
        beanFactory.addBeanPostProcessor(new ImportAwareBeanPostProcessor(beanFactory));
    }

where processConfigBeanDefinition() is responsible for setting up the IMPORT_REGISTRY_BEAN_NAME but it might not. It is normally called from postProcessBeanDefinitionRegistry() but even then it might not add the ImportRegistry. And then ImportAwareBeanPostProcessor is registered unconditionally, and it expects there to be a IMPORT_REGISTRY_BEAN_NAME. It barfs if it's not there.

Possibly this never arises in a "normal" Spring application, but many things can happen to prevent processConfigBeanDefinitions() from adding that ImportRegistry (currently we are looking at an example in a native image), so probably the ImportAwareBeanPostProcessor should either only be added if the IMPORT_REGISTRY_BEAN_NAME is present, or should check before using it that it is there.

Comment From: sbrannen

When you say it barfs, I guess you're saying it throws an exception for the this.beanFactory.getBean(IMPORT_REGISTRY_BEAN_NAME, ImportRegistry.class) invocation in postProcessBeforeInitialization(...), and that's what you want to avoid -- right?

Comment From: dsyer

Yes, that's it.

Comment From: sbrannen

I've labeled this issue as blocked until it is determined why the ImportRegistry is not present as a singleton bean in the GraalVM native image sample application in which this occurs.

/cc @dsyer @sdeleuze

Comment From: sbrannen

@dsyer, do you still consider this an issue worth investigating further?

Comment From: dsyer

Practically speaking, probably not. I mean it's still a code path that I can't see is ruled out, and it might help to be defensive. But on the other hand I think it would be hard to reproduce.

Comment From: sbrannen

Thanks for the feedback, @dsyer. In light of that, I am closing this issue.

We can re-open it if any further issues are encountered.