Prototype bean in parent, dependency in child context

[jcarreira]

I'm working on implementing hierarchical contexts, and I've run into a situation I assumed would be handled... I've got a prototype bean definition in my parent context which has a property of type Counter (for example). In my child context (which has its parent set to the parent context) I define the Counter bean. Now, when I do a getBean() on the BeanFactory of the child context for the prototype bean defined in the parent context, I would expect that its dependencies from the child context would be initialized, but they're not.

I think it's a problem with AbstractBeanFactory in the getBean(String name, Class requiredType, Object[] args) method where it does this:

try {
				mergedBeanDefinition = getMergedBeanDefinition(beanName, false);
			}
			catch (NoSuchBeanDefinitionException ex) {
				// Not found -> check parent.
				if (this.parentBeanFactory instanceof AbstractBeanFactory) {
					// Delegation to parent with args only possible for AbstractBeanFactory.
					return ((AbstractBeanFactory) this.parentBeanFactory).getBean(name, requiredType, args);
				}
				else if (this.parentBeanFactory != null && args == null) {
					// No args -> delegate to standard getBean method.
					return this.parentBeanFactory.getBean(name, requiredType);
				}
				throw ex;
			}

The problem is that if it's defined in this context, it goes on to do some other initialization, whereas if it's defined in the parent context it just returns. I think if the parent context's bean definition is a prototype, it should go ahead and do some more initialization / autowiring to give it all of its dependencies.

I don't want to have to define the beans which use the child objects for each and every child context when they're the same across all of them (more for performance and memory use than anything else). [/code]

[Andreas Senft]

Afaik it's by design that application contexts are strictly hierarchical. That means that a parent context does not know anything of child contexts. Therefore I fear your callback strategy will not work.

For partitioning purposes maybe the import mechanism might be useful.

Regards,
Andreas

[jcarreira]

That's all well and good in a theoretical, pure hierarchy world... Unfortunately it falls down in the real world, so I think the container should be more pragmatic about managing hierarchical dependencies. What if you wanted to override a certain type of dependency in a child context and have it show up in prototype beans defined in the parent? I can think of lots of places where this would be useful (different datasources in different child contexts, for instance), but that's not currently possible.

I've worked around this, for now, by doing another call to autowire the beans I get back from the context using the child container, which ends up finding the dependencies required for the prototype bean, but it's definitely sub-optimal.

Thanks for your reply.... I'm glad to see that someone can actually see these posts, since I almost never get a response.

[Andreas Senft]

I've worked around this, for now, by doing another call to autowire the beans I get back from the context using the child container, which ends up finding the dependencies required for the prototype bean, but it's definitely sub-optimal.

I never needed such a functionality yet. Though I can indeed imagine scenarios where it could be useful. So if you can provide a mechanism that decently solve this problem it's maybe worth to be proposed as enhancement to Spring.

Regards,
Andreas