Dynamically picking Spring-Application-Context file

[Gemini Moses]

We have a requirement that needs mapping certain bean to different class based on a flag value.

The flag value is read form DB and if flag is ON , we want Spring to use
Spring-Application-Context-A file
If flag is OFF , we want spring to use
Spring-Application-Context-B file.

Both will have same beanIDs but class names mapped to it will be different.

How can we do this?

Thanks!

[Mark Secrist]

One approach you might consider is subclassing the ContextLoaderListener class and override the contextInitialized method. The standard ContextLoaderListener method basically looks like:

 
	public void contextInitialized(ServletContextEvent event) {
		this.contextLoader = createContextLoader();
		if (this.contextLoader == null) {
			this.contextLoader = this;
		}
		this.contextLoader.initWebApplicationContext(event.getServletContext());
	}
   

Your typical configuration in a web application would be to set the web application ContextParams for contextConfigLocation to point to additional bean files to load. This value is available in the contextInitialized() method via the event object passed in. You could probably simply write this value to be whatever bean files you wanted your contextConfigLocation to reference based on the value in the database.

Keep in mind your beans won't be initialized at that point so you'll have to find some alternative way to query the database.

[Gemini Moses]

Thanks Mark.

Can BeanFactoryPostProcessors / BeanPostProcessors be used for this purpose?
If so Which approach do you think is better.

Thanks!

[Mark Secrist]

The problem is related to the IOC container lifecycle. BeanFactoryPostProcessor gets run after the context (and bean definitions) are already loaded but before any beans get intantiated. If you are wanting to switch out entire bean definitions based on the database switch then it's already too late by the time postProcessBeanFactory gets run.

The BeanPostProcessor allows customization of a particular bean after instantiation but either before or after initialization. If it were a matter of using the same bean in either case but different configuration, this might be the place to do it. If you are wanting a completely different bean, you might be able to do it here but it would be a completely custom solution and would likely be difficult to maintain.