2-stage construction

[fashoom]

I've never liked having to write individual setter methods for every class member to accomodate 2-stage construction. It appears this is no longer necessary w/ JavaConfig, unless I misunderstand. Can I use a single init method for 2nd stage c-tion as below w/o causing circular dependency exceptions?

@Configuration
public class AppConfig {
@Bean
public Clock clock() {
Clock clock = new Clock();
clock.init(ruler(), mind());
return clock;
}

@Bean
public Ruler ruler() {
Ruler ruler = new Ruler();
ruler.init(clock(), mind());
return ruler;
}

@Bean
public Mind mind() {
Mind mind = new Mind();
mind.init(ruler(), clock());
return mind;
}
}

[fashoom]

or perhaps circular dependency exceptions are prevented by the way javaconfig handles @Bean?

@Configuration
public class AppConfig {
@Bean
public Clock clock() {
return new Clock(ruler(), mind());
}

@Bean
public Ruler ruler() {
return new Ruler(clock(), mind());
}

@Bean
public Mind mind() {
return new Mind(ruler(), clock());
}
}

[Chris Beams]

XML config is more flexible than JavaConfig when it comes to circular dependencies. For details, check out http://jira.springframework.org/browse/SJC-94

[fashoom]

Wow, this is a deal-breaker for me and my organization. Support for circular-dependencies is one of the greatest benefits of Spring. I was hoping Javaconfig supported circular dependencies in c-tor injection, and it doesn't even support them in setter injection? IMHO this is a must fix.

[Chris Beams]

Unfortunately, there's nothing to 'fix'. This is a natural limitation of the way that JavaConfig works, because it's the way that Java itself works. Because you're given programmatic control over bean creation within the bounds of a @Bean method, any circular dependencies between @Bean methods will cause a stack overflow.

Circular constructor dependencies is impossible no matter what (Spring XML cannot handle this either). Circular setter dependencies requires decoupling construction from property wiring completely. This is what Spring XML does, and you can achieve the same effect through JavaConfig if you use bean autowiring (this is documented in the issue I linked to before). Bottom line, however, is that if you have many beans that need support for circular wiring, you're likely better off wiring at least those beans with XML. While JavaConfig can technically do it, it's not really 'first class' support like XML, nor will there likely be such support - it doesn't mesh well with the 'JavaConfig way'.

Remember also that JavaConfig and XML integrate very nicely together, so if there are beans you need to wire in XML you can access them from JavaConfig and vice versa. Check out ConfigurationPostProcessor and @ImportXml if you're not already aware of both.