Documentation about behaviour of DI is misleading (and perpetuated in the forums) [SPR-3732]

[spring-projects-issues]

nigel magnay opened SPR-3732 and commented

section 3.3.1.2. Constructor Injection states :

Finally, if it is not immediately apparent, it is worth mentioning that when one or more collaborating beans are being injected into a dependent bean, each collaborating bean is totally configured prior to being passed (via one of the DI flavors) to the dependent bean. This means that if bean A has a dependency on bean B, the Spring IoC container will totally configure bean B prior to invoking the setter method on bean A; you can read 'totally configure' to mean that the bean will be instantiated (if not a pre-instantiated singleton), all of its dependencies will be set, and the relevant lifecycle methods (such as a configured init method or the IntializingBean callback method) will all be invoked.

Questions such as the following

Is it guaranteed that when the Spring container calls the property setters or the constructor, then the objects passed in as arguments are already initialized? For example, if I have setFoo(Bar foo), then can setFoo be sure that foo is an initialized object, i.e. its afterPropertiesSet or custom init-method was already called? (The documentation only says that "the dependency is properly initialized before the dependent bean".)

Are answered with

I can absolutely, 100% satisfaction guaranteed, indubitably confirm that the answer to your question is in the affirmative.

But, in actual fact, this isn't "100% satisfaction guaranteed" correct. Observing the discussion around #6186, specifically the comments, it is plain that the container will not have called the initialize instruction if there is a circular dependency around initialization. You will only see this noted if you pump JUnit all the way up to DEBUG level, in which case you get statement buried in your now hyper-verbose output such as

Returning eagerly cached instance of singleton bean 'A' that is not fully initialized yet - a consequence of a circular reference

At the very minimum, the documentation needs to be corrected to make this plain (even if it's an edge case, it's a fairly fundamental one) - perhaps in a sidebar. I'd prefer to be able to make the container throw an exception, but just knowing that this is the behaviour would be good...

---

Affects: 2.0.6

[spring-projects-issues]

Rick Evans commented

Hi Nigel

Yeah fair point. I was being a bit disingenuous when I wrote that reply (not in a bad way, but still).

It is a corner case, because in 4 years of Spring I honestly haven't encountered this issue. However, it does need to be mentioned in the reference documentation.

Cheers
Rick

[spring-projects-issues]

Mark Fisher commented

The "Circular Dependency" sidebar now includes a brief discussion of the impact on initialization order of beans that are involved in a circular dependency. This should be available beginning with the 2.1 nightly snapshot #206.