Apr 8th, 2008, 05:50 AM
Dynamic bean definition problem
Hopefully someone can help me with my ApplicationContext-problem here.
We currently have a spring-based server-app, based on one DispatcherServlet, exporting webservices via HttpExporter. The overall Goal is to implement a scenario with multiple DataSources and SessionFactories as discussed here:
The actual SessionFactory is to be delivered at runtime by some SessionFactoryFactory, backed by a HashMap of factories.
In our very scenario we would like to be able to define(!) and instantiate new DataSources and SessionFactories at runtime. From what I learned from the forum and the documentation, on would use BeanDefinitionRegistry in such a case, in order to create new DataSource- and SessionFactory-bean-definitions and register them with the context.
The problem is now, that when using the standard implementation of DispatcherServlet or ContextLoader, I can not declare these to use GenericWebApplicationContext, as this would implement BeanDefinitionRegistry. As I understand the documentation, ConfigurableXYApplicationContext does NOT implement BeanDefinitionRegistry and thus does not allow adding bean-definitions at runtime.
Does anybody have a suggestion on how to set up such a context, or context-hierarchy?
Of course all the other beans should still be configured with xml.
Thanks and Regards,
Apr 9th, 2008, 12:34 PM
I'm trying to do something similar, but haven't figured it out either.
I'm using the Spring ContextLoaderListener to initialize a WebApplicationContext. However the XmlWebApplicationContext that gets created by default does not implement BeanDefinitionRegistry.
It is possible to provide a context class as a parameter to the ContextLoader in web.xml, however the ContextLoader requires that the passed class implement ConfigurableWebApplicationContext - which does not have any (usable) implementations that also implement BeanDefinitionRegistry.
I tried creating a nested GenericApplicationContext within my config XML, however this causes other issues for me because then the parent context cannot access the beans within that child context.
Have you had any other ideas since posting?