Skip to content

Adjus registration order of BeanDefinition declared by @Configuration #35008

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xinbimingjingtai opened this issue Jun 7, 2025 · 1 comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on

Comments

@xinbimingjingtai
Copy link

While I tried to customize an AutoConfiguration, but @ConditionalOnBean did not working, then I tried to find the problem through examples, source code, and the Internet, and used different configuration methods, and finally found that it was because of the registration order of BeanDefinition.

In my opinion, their registration order should be like this:

  1. Configuration
  2. beans annotated on Configuration (e.g. @Import and @EnableConfigurationProperties)
  3. (static) InnerConfiguration
  4. @bean method

Then about ConfigurationClassParser, the (static) InnerConfiguration should be managed by the fields in ConfigurationClass of Configuration, and if the Conditional of Configuration is not matched, then InnerConfiguration should also be skipped, ConfigurationClassBeanDefinitionReader will be like:

private void loadBeanDefinitionsForConfigurationClass(
			ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {

		if (trackedConditionEvaluator.shouldSkip(configClass)) {
			String beanName = configClass.getBeanName();
			if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
				this.registry.removeBeanDefinition(beanName);
			}
			this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
			return;
		}

		if (configClass.isImported()) {
			registerBeanDefinitionForImportedConfigurationClass(configClass);
		}
                 
		loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
		loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
		loadBeanDefinitionsFromInnerConfigurationClass(configClass.getInnerConfigurationClass()); // something like this

		for (BeanMethod beanMethod : configClass.getBeanMethods()) {
			loadBeanDefinitionsForBeanMethod(beanMethod);
		}
	}

demo2.zip

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 7, 2025
@bclozel
Copy link
Member

bclozel commented Jun 7, 2025

Let's take a step back.
Instead of describing the implementation changes you want, can you explain what are you trying to achieve and why it doesn't work?

@bclozel bclozel added status: waiting-for-feedback We need additional information before we can continue in: core Issues in core modules (aop, beans, core, context, expression) labels Jun 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on
Projects
None yet
Development

No branches or pull requests

3 participants