Clarify @Bean(autowire=NO) [SPR-14282]

[spring-projects-issues]

Rob Winch opened SPR-14282 and commented

Given the following classes:

public class Foo {

	@Autowired
	Bar bar;
}

public class Bar { }

@Configuration
public class Config {

	@Bean
	public Foo foo() {
		return new Foo();
	}

	@Bean
	public Bar bar() {
		return new Bar();
	}
}

It is not logical that the following test will fail since the autowire attribute on @Bean is by default NO:

try (AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext()) {
	ctx.register(Config.class);
	ctx.refresh();

	Foo foo = ctx.getBean(Foo.class);

	assertThat(foo.bar, nullValue());
}

---

Affects: 3.2.17, 4.2.6, 4.3 RC2

Issue Links:

• Should @Configuration mark @Inject fields and setters as satisfied (injected)? [SPR-14180] #18751 Should @Configuration mark @Inject fields and setters as satisfied (injected)?

Referenced from: commits 7da1295, 98eaf05, a0a2a33

Backported to: 4.2.7, 3.2.18

[spring-projects-issues]

Rob Winch commented

I added a PR to the spring-framework-issues repository which demonstrates this issue. See spring-attic/spring-framework-issues#128

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is by design: that autowire attribute just controls externally declared autowiring, analogous to XML bean definitions, with no influence over annotation-driven injection points. The default 'no' simply means no externally driven autowiring convention.

[spring-projects-issues]

Rob Winch commented

Thanks for the fast reply. The intended behavior seems to conflict with the Javadoc which states:

NO

Constant that indicates no autowiring at all.

It's also inconsistent with the XML configuration. It would also be really nice to be able to disable autowiring on a @Bean that has @Autowired on it.

[spring-projects-issues]

Juergen Hoeller commented

Good point, we should at least reword the javadoc there...

[spring-projects-issues]

Rob Winch commented

Juergen Hoeller Thanks for the response.

I'm curious about the rational between what appears to be a big difference between:

<bean class="..." autowire="no" />

and

@Bean(autowire=NO)

It seems that the behavior you are describing for @Bean(autowire=NO) is more aligned with

<bean class="..." autowire="default" />

I understand that there are passivity concerns in the mix here. However, I'd also really like to be able to disable autowiring for a @Bean as I am able to do with XML. Is this something that would be considered as an enhancement?

[spring-projects-issues]

Juergen Hoeller commented

The behavior is identical to the XML equivalent. "default" there just refers to the default value of the attribute at the <beans> level; the effective default is "no", with the following comment:

Note that this default mode also allows for annotation-driven autowiring,
if activated. "no" refers to externally driven autowiring only, not
affecting any autowiring demands that the bean class itself expresses.

So I guess we should have a similar note on @Bean. I'm even wondering whether we should deprecate the autowire attribute altogether since it is not really idiomatic there.

For your purposes, we'd have to introduce some mechanism on AutowiredAnnotationBeanPostProcessor that allows for suppressing annotation-driven autowiring to begin with. I rather see this as a separate flag on @Bean, next to a deprecated autowire attribute.

[spring-projects-issues]

Juergen Hoeller commented

I've added a clarifying remark to @Bean's javadoc for the purposes of this ticket. Let's discuss ways to suppress annotation-driven autowiring separately.