Announcement Announcement Module
Collapse
No announcement yet.
Chained BeanFactories and name resolution Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chained BeanFactories and name resolution

    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?

  • #2
    Originally posted by cheezit
    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

    Comment


    • #3
      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.

      Comment

      Working...
      X