Skip to content

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

Closed
@spring-projects-issues

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    in: coreIssues in core modules (aop, beans, core, context, expression)type: taskA general task

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions