@Bean 'lite' mode not supported if @Bean methods are not declared locally

[quaff]

I'm not sure it's a bug or undocumented limitation.

If no @Bean defined in Config then @Bean defined in BaseConfig will be ignored.

@ContextConfiguration(classes = Config.class)
@ExtendWith(SpringExtension.class)
public class InjectionTests {

	@Autowired
	private String bean1;

	@Autowired
	private String bean2;

	@Test
	void test() {
		assertThat(bean1).isEqualTo("bean1");
		assertThat(bean2).isEqualTo("bean2");
	}

}

class Config extends BaseConfig {

}

class BaseConfig {
	@Bean
	String bean1() {
		return "bean1";
	}
	@Bean
	String bean2() {
		return "bean2";
	}
}

there are many workarounds

1. move any one of @Bean to Config

class Config extends BaseConfig {
	@Bean
	String bean2() {
		return "bean2";
	}
}

class BaseConfig {
	@Bean
	String bean1() {
		return "bean1";
	}
}

2. mark @Configuration or @Component on Config

@Configuration
// @Component
class Config extends BaseConfig {

}

class BaseConfig {
	@Bean
	String bean1() {
		return "bean1";
	}
	@Bean
	String bean2() {
		return "bean2";
	}
}

3. use @Import instead of ContextConfiguration

@Import(Config.class)
@ExtendWith(SpringExtension.class)
public class InjectionTests {

	@Autowired
	private String bean1;

	@Autowired
	private String bean2;

	@Test
	void test() {
		assertThat(bean1).isEqualTo("bean1");
		assertThat(bean2).isEqualTo("bean2");
	}

}

[snicoll]

@quaff neither? This has nothing to do with ContextConfiguration as far as I can see. 2. is what you should be doing all along if you want that class to be processed as a configuration class.

[quaff]

@quaff neither? This has nothing to do with ContextConfiguration as far as I can see. 2. is what you should be doing all along if you want that class to be processed as a configuration class.

@snicoll I know option 2 is recommended, I think there is something arguable here.
Can plain class be imported as configuration class?
If no, then workaround 1 and 3 should be prohibited since they are supported by accident.
If yes, then the inconsistency should be fixed.

[snicoll]

I know option 2 is recommended

That's not a recommendation. The stereotype must be applied, otherwise the context is using a fallback called "lite mode".

Can plain class be imported as configuration class?

Yes and it's then treated with "lite mode", see https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-java-basic-concepts

[quaff]

I know option 2 is recommended

That's not a recommendation. The stereotype must be applied, otherwise the context is using a fallback called "lite mode".

Can plain class be imported as configuration class?

Yes and it's then treated with "lite mode", see https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-java-basic-concepts

AFAIK, the lite mode only affects inter-bean dependencies, that's said it should equals to @Configuration(proxyBeanMethods = false) or @Component, with my case I need move one of @Bean from super class to child class, then It act like the lite mode, does this restriction is expected and documented?

[snicoll]

Sorry @quaff, I thought this was one property of lite mode but that doesn't seem to be the case. Maybe @sbrannen knows why @ContextConfiguration behaves this way?

[sbrannen]

I don't believe this is specific to @ContextConfiguration.

Rather, I believe the described behavior is due to the semantics of ConfigurationClassUtils.isConfigurationCandidate(AnnotationMetadata) which delegates to hasBeanMethods(AnnotationMetadata) which (AFAICT by inspection) does not search for @Bean methods in super types.

But that's just an assumption. I'd have to create tests to verify/debug it.

[quaff]

This method doesn't check super class has bean methods, I'm trying to provide PR.

spring-framework/spring-context/src/main/java/org/springframework/context/annotation/ConfigurationClassUtils.java

Lines 179 to 189 in 993a69d

	static boolean hasBeanMethods(AnnotationMetadata metadata) {
	try {
	return metadata.hasAnnotatedMethods(Bean.class.getName());
	}
	catch (Throwable ex) {
	if (logger.isDebugEnabled()) {
	logger.debug("Failed to introspect @Bean methods on class [" + metadata.getClassName() + "]: " + ex);
	}
	return false;
	}
	}

[snicoll]

Sam, your quote is outdated. I already explained I thought this was a "feature" of lite mode.

Whatever the underlying util this calls, it's very odd that it behaves differently than what @Import does.

[quaff]

Sam, your quote is outdated. I already explained I thought this was a "feature" of lite mode.

Whatever the underlying util this calls, it's very odd that it behaves differently than what @Import does.

Yes, It split to two issues.

1. Fix hasBeanMethods(AnnotationMetadata)
2. Fix inconsistency between @ContextConfiguration and @Import

[sbrannen]

@snicoll, my quote is not outdated.

I was replying directly to your previous question:

Maybe @sbrannen knows why @ContextConfiguration behaves this way?

As I pointed out in #30449 (comment), it's not @ContextConfiguration behaving in any special way.

Rather, it's standard behavior from spring-context.

[sbrannen]

it's very odd that it behaves differently than what @Import does.

Agreed, if the semantics between class registration and @Import are different it is rather unexpected.

[sbrannen]

Fix inconsistency between @ContextConfiguration and @Import

Again, this is not related to @ContextConfiguration or the TestContext framework.

Rather, this is the standard behavior for a Class registered directly with an ApplicationContext -- for example, using AnnotatedBeanDefinitionReader or AnnotationConfigApplicationContext.

For that use case, a non-annotated class must have a local @Bean method declared in order for the class to be processed using @Bean 'lite' mode.

In contrast, any class imported with @Import will be processed as a @Configuration class.

spring-framework/spring-context/src/main/java/org/springframework/context/annotation/ConfigurationClassParser.java

Lines 509 to 515 in 993a69d

	else {
	// Candidate class not an ImportSelector or ImportBeanDefinitionRegistrar ->
	// process it as an @Configuration class
	this.importStack.registerImport(
	currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
	processConfigurationClass(candidate.asConfigClass(configClass), exclusionFilter);
	}

This method doesn't check super class has bean methods, I'm trying to provide PR.

Technically speaking, changing that behavior would be a breaking change. So if we decide to do that, it would likely have to be in 6.1

@jhoeller, thoughts?

[quaff]

@sbrannen I've submitted #30462

[quaff]

In contrast, any class imported with @Import will be processed as a @Configuration class.

spring-framework/spring-context/src/main/java/org/springframework/context/annotation/ConfigurationClassParser.java

Lines 509 to 515 in 993a69d

	else {
	// Candidate class not an ImportSelector or ImportBeanDefinitionRegistrar ->
	// process it as an @Configuration class
	this.importStack.registerImport(
	currentSourceClass.getMetadata(), candidate.getMetadata().getClassName());
	processConfigurationClass(candidate.asConfigClass(configClass), exclusionFilter);
	}

It explain the difference and it's expected behavior, we should improve the document.

This method doesn't check super class has bean methods, I'm trying to provide PR.

Technically speaking, changing that behavior would be a breaking change. So if we decide to do that, it would likely have to be in 6.1

IMO it's a fix and should be backported to 5.x also.

[sbrannen]

• Superseded by Support @Bean 'lite' mode when no @Bean methods are declared locally #30462

[snicoll]

@snicoll, my quote is not outdated.

It wasn't a quote so it can't be. Sorry, I thought you were quoting me.

The PR that supersedes this issue has been closed and I agree with that but I still wonder if any other user-facing API ends up using the code in spring-context this way.

What I meant with outdated is that I now think this is a problem with @ContextConfiguration. If @Import works differently, this doesn't look right as they are supposed to mean the same thing, don't they? Juergen mentioned that we can't crawl the parent for @Bean methods and that makes sense if you're working at the ASM level but that's not the case here. @ContextConfiguration refers to classes, just like @Import. Can we please revisit this?

[sbrannen]

@snicoll, my quote is not outdated.

It wasn't a quote so it can't be. Sorry, I thought you were quoting me.

Ahhh, OK. I understand the confusion now. Thanks for clarifying. 👍

The PR that supersedes this issue has been closed and I agree with that

I only partially agree with that, which I will elaborate on below.

but I still wonder if any other user-facing API ends up using the code in spring-context this way.

Yes, this is the "standard" behavior for "annotated classes" that are registered directly with an ApplicationContext.

For example, the following demonstrates the same undesired behavior without using any part of the TestContext framework.

class BeanLiteModeTests {

	@Test
	void test() {
		try (var context = new AnnotationConfigApplicationContext(Config.class)) {
			var bean1 = context.getBean("bean1", String.class);
			var bean2 = context.getBean("bean2", String.class);

			assertThat(bean1).isEqualTo("bean1");
			assertThat(bean2).isEqualTo("bean2");
		}
	}

	// @org.springframework.stereotype.Component
	static class Config extends BaseConfig {
	}

	static class BaseConfig {
		@Bean
		String bean1() {
			return "bean1";
		}

		@Bean
		String bean2() {
			return "bean2";
		}
	}

}

If @Import works differently, this doesn't look right as they are supposed to mean the same thing, don't they?

Yes, I agree: @ContextConfiguration and @Import should ideally provide the same semantics.

What I meant with outdated is that I now think this is a problem with @ContextConfiguration.

Based on the example I provided above, I would say it's an issue with "registering classes directly with an application context" in general.

Juergen mentioned that we can't crawl the parent for @Bean methods and that makes sense if you're working at the ASM level but that's not the case here.

Right. If the classes are picked up via component scanning, I agree that we should not scan the class hierarchy for @Bean methods.

@ContextConfiguration refers to classes, just like @Import.

That's the key differentiator!

Any time the user supplies Class references directly, I think the semantics should be the same as when classes are supplied via @Import.

In other words, whenever a Class is registered with an ApplicationContext, I think it would make sense to process the class "as a configuration class" just like the code path for @Import.

If we made a change along those lines, then AnnotatedBeanDefinitionReader, AnnotationConfigApplicationContext(Class<?>...), and @ContextConfiguration would have the same semantics as @Import (with regard to @Bean lite mode).

Can we please revisit this?

Yes, thanks for reopening the issue.

[sbrannen]

@jhoeller, what do you think about having consistent semantics for @Bean 'lite' mode when Class references are registered directly with an ApplicationContext?

I suppose the alternative would be to change the behavior of @ContextConfiguration so that classes are registered with @Import semantics (if feasible), but I believe that would require changes in Spring Boot and any other custom SmartContextLoader implementations.

[sbrannen]

@jhoeller, what do you think about having consistent semantics for @Bean 'lite' mode when Class references are registered directly with an ApplicationContext?

Update: I've prototyped an implementation for this which treats any Class registered via AnnotatedBeanDefinitionReader as a @Configuration class candidate with @Bean 'lite' mode semantics.

main...sbrannen:spring-framework:issues/gh-30449-bean-lite-mode-for-registered-classes

[sbrannen]

This has been addressed in commit a455317 and can be tested in upcoming snapshots for 6.0.10.