Circular dependence forbidding cannot be easily configured. [SPR-2048]

[spring-projects-issues]

Antranig Basman opened SPR-2048 and commented

See #6186 and #5254.

Personally I consider the change in defaults to allow circular bean references by default (somewhere around Spring 1.2.2 I believe) was a bad mistake - now the central contract of Spring, that a bean is "fully constructed" before it is delivered as a dependency is broken. As well as being conceptually incoherent, this has practical consequences - for example on a project I am working with, around a week of deployers' time has been taken up chasing a "phantom" problem actually caused by a race condition resulting from Spring's order of instantiation of singletons that were participating in a circular reference in a 3rd-party library. I think for "inexperienced" developers to get circular references silently supported by default is a recipe for trouble.

However, the decision was taken too long ago to do much about, but it would be great if in the meantime it were made a good deal easier for the "casual" user of Spring to re-enable the old behaviour of forbidding circular references - the flag Juergen refers to in #6186 is too low-level and can't be easily handed out as a "standard practice" to our team.

---

Affects: 2.0 M4

Issue Links:

• Make it easier to disallow bean definition overriding [SPR-3734] #8415 Make it easier to disallow bean definition overriding

1 votes, 1 watchers

[spring-projects-issues]

Juergen Hoeller commented

setAllowCircularReferences and setAllowBeanDefinitionOverriding are not only available on ClassPathXmlApplicationContext since 2.5.2 but also on our new GenericXmlApplicationContext now. The typical usage model looks like as follows, with refresh called explicitly:

GenericXmlApplicationContext context = new GenericXmlApplicationContext();
context.setAllowCircularReferences(false);
context.load("myResource.xml", "otherResource.xml");
context.refresh();

I recommend creating custom ApplicationContext subclasses (from GenericXmlApplicationContext or ClassPathXmlApplicationContext, as you prefer) if you're always expecting specific settings, simply pre-populating those flags in the subclass constructor.

Juergen