A depends on B depends on A

[Edward Kenworthy]

Looks like a circular dependency and for bean factory purposes it is (but because of the class hierarchy actually it isn't in fact).

Problem is that A needs to have B injected into it and vice versa.

The way I've solved it is:

1. declare A.
2. declare B and inject A. B then injects itself into A (programmatically).

Is there a better way of doing this in Spring?

[Andreas Senft]

That could not be solved in a straightforward manner.
How would you do it programmatically? You would need a component which instantiates both classes and set the references to each other afterwards.

In contrast to this, the approach in spring is to finish one bean a time (instantiation + setting of properties). Hence, circular dependencies are problematic.

I can propose you following approaches:
1. Implement your setters so that they synchronizes themselves. If you assign an A to a B the backward reference will be set automatically. I guess this is similar to your current approach.

2. You can use lookup-method injection for one of the classes (see reference documentation chapter 3.3.3.1)

3. You can use a BeanPostProcessor which sets the backward references of dedicated beans.

Hope that helps,
Andreas

[Edward Kenworthy]

Hi Andreas

Thanks for the pointers, very interesting I'll have to go have a look at your 2 & 3.

Cheers

Edward

[David Harkness]

Following Andreas's advice, I used lookup-method injection, and it worked great. In my case, I have a bean that needs to call another of its methods (same bean) through its own transaction proxy. Not exactly as your case, Edward, but still a circular reference.

Since this is a singleton bean, and LMI is activated on every call (returning the same reference), I created a private member "self" and an associated accessor pair. In the getter, I check if self is null, and if so call the LMI method "getProxiedSelf". This way the proxy is looked up only once and cached in the member variable.

Thanks guys for asking and answering my question!

[DMCG]

I've also been grappling with this problem, and went with solution 3 for the case of a number of beans which need depend on, and are ultimately depended on by, a JFrame. Using this approach I can do a whole batch at once. I'm just finding my feet with Spring though, does this seem sensible?

public class NeedsFramePostProcessor implements BeanFactoryPostProcessor {

private final JFrame frame;

public NeedsFramePostProcessor(JFrame frame) {
this.frame = frame;
}

public void postProcessBeanFactory(ConfigurableListableBeanFac tory beanFactory)
throws BeansException {
Map beans = beanFactory.getBeansOfType(NeedsFrame.class, false, false);
for (Iterator iter = beans.values().iterator(); iter.hasNext() {
NeedsFrame element = (NeedsFrame) iter.next();
element.setFrame(frame);
}
}
}