Determining which root WebApplicationContext to use at runtime

I need to be able to override the 'parentContextKey' servletContext initial parameter that is specified in the web.xml file. This is the key that is used by the ContextSingletonBeanFactoryLocator to assign the parent context to the root WebApplicationContext. I need to be able to override this value with a different one, possibly keyed by a system property or other mechanism which will enable the override. Additionally, the WebApplicationContext configuration files for the child need to be different depending on the parent key being used.

I've written a new ContextLoader that subclasses Spring's ContextLoader and have had success getting the dynamic parentContextKey working to some degree. It works when the parents are all ClassPathXmlApplicationContexts, but not when they are XmlWebApplicationContexts (I've tried rolling up the root WebApplicationContext as two separate bean group definitions into the parent). Some of the beans are definitely web-specific and require the ServletContext, so changing them to ClassPathXmlApplicationContexts really is not an option.

An XmlWebApplicationContext needs the ServletContext in order to process, and ContextSingletonBeanFactoryLocator has no notion of ServletContext. So now I'm thinking about extending ContextSingletonBeanFactoryLocator to take a ServletContext as input, but I'm wondering if this is getting too complicated. Has anyone else tried doing anything like this before?

By the way, the reason I need this override capability is because we are working in a team environment, and we often need to switch between a local and live configuration without disrupting or altering the web.xml file.

I quickly wanted to clarify that I not only want to override what is in parentContextKey but also the config files specified under contextConfigLocations. I had originally tried to roll up the contextConfigLocations files into the parent definition itself, but I ran into problems with the ServletContext as previously described.

Perhaps implementing the contextConfigLocations as a child rather than rolling up into the parent would work better?

Thanks in advance,
Jonathan