Chained BeanFactories and name resolution

[cheezit]

I have two BeanFactory instances:
- an XmlBeanFactory that reads my core config
- a custom BeanFactory ("DynamicBeanFactory") that interacts with the XmlBeanFactory to support beans that are not in the XML config.

I have the XmlBeanFactory as the parent of the DynamicBeanFactory. If I call getBean() on the DynamicBeanFactory, it checks the parent first to get a "template" bean, then applies some logic to synthesize a "dynamic bean" if necessary.

This works great--however, I would like to define a bean in my XML config that takes a reference to a "dynamic bean". This would be possible if the DynamicBeanFactory were a parent of the XmlBeanFactory---but it is already a child!

Is there any way for a BeanFactory to resolve bean names "globally" across the full chain that they participate in, including children?

[Andreas Senft]

Is there any way for a BeanFactory to resolve bean names "globally" across the full chain that they participate in, including children?

Not that I'm aware of (at least not out-of the box).
I just wonder what kind of logic your DynamicBeanFactory applies to the templates. Maybe there could be an alternative approach (FactoryBean, BeanPostProcessor) that could work out of the box.

Regards,
Andreas

[cheezit]

I solved this problem by subclassing XmlBeanFactory, which allows me to access the singleton cache, and ensures that when the XML config is parsed, my subclass gets a chance to create any new beans if necessary. I am using a special bean name format to indicate that it is a dynamic bean.

In answer to your question, what I am working on is a domain-specific instance of the Spring remoting approach. I want to be able to support proxy beans that may need to point to a remote location that is not known ahead of time, but I don't want to lose the ability to have the proxies appear as local beans (because sometimes they will be, and setting a remote URL on local VM-resident proxy doesn't make sense). I also want to ensure that I have a singleton object per remote endpoint so I can do client-side queueing.

My solution is to use the bean name as the dynamic element that triggers whether the bean is local or in fact remote.