ApplicationContextInitializer and contextConfigLocation ?

[Tom Zeller]

> Another idea:  Since the problem with the above is the way that property
> replacement is done on the config locations when you call
> context.setConfigLocations(), you could just use a custom subclass of the
> default web application context type, and override either its
> setConfigLocations() or maybe its resolvePath() or something.  Note that you
> can specify the type of root context that it will create using the
> 'contextClass' servlet context param in web.xml.

I worked out your idea :

public class DelayPropertyReplacementContext extends XmlWebApplicationContext {

 private boolean propertySourcesInitialized = false;

 protected void initPropertySources() {
   super.initPropertySources();
   propertySourcesInitialized = true;
   super.setConfigLocations(super.getConfigLocations());
 }

 protected String resolvePath(String path) {
   if (propertySourcesInitialized) {
     return super.resolvePath(path);
   }
   return path;
 }

It resolves contextConfigLocation properties _after_ property sources
have been initialized.

So, I guess this is an alternative to requiring the idp.home system
property and/or the custom ServletContextListener which would set
idp.home as a system property if not already set.