`@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.