ApplicationContextInitializer and contextConfigLocation ?

[Brent Putman]

On 6/12/14 6:08 PM, Tom Zeller wrote:
>
> With "${idp.home:}" the context will
> load, but then the property is replaced with "" so it cannot be
> resolved again via setConfigLocations(getConfigLocations()). 

I think there may be yet another option there that just occurred to me. 
Since in the ACI for a WebApplicationContext you have access to the
ServletContext, you could just ignore what is in getConfigLocations(),
and pull the original values with the ${...} tokens straight out of the
servlet context param.  Then do your property replacement on them and
set them with context.setConfigLocations().  Might work?

Another random idea:  I'm not sure if the ordering of execution of
ServletContextListeners can be guaranteed, but if it can:  You could
have one that runs before the Spring ContextLoaderListener and whose
purpose is to process whatever system properties are there, well-known
locations, etc and have it ensure that the idp.home is set.  Then the
standard Spring code in ContextLoaderListener will just resolve idp.home
out of system properties using the syntax you already showed.

If the ordering can't be guaranteed:  You still might be able to do
something similar by subclassing the Spring ContextLoaderListener and
having it do the system property munging before it invokes the
superclass logic.