ApplicationContextInitializer and contextConfigLocation ?

[Tom Zeller]

> So I imagine you could do your own property replacement on the context
> config location string(s) by using ConfigurableWebApplicationContext
> #getConfigLocations() and #setConfigLocations().
>
> Actually, it looks like setConfigLocations() might actually do property
> replacement at the time it is called - but in the init of the root web
> application context that is called before the ACIs get called, so your
> custom PropertySource isn't there yet.  Forcing the property replacement on
> those in your ACI might be as simple as calling
> context.setConfigLocations(context.getConfigLocations()) *after* you've
> added your custom property source, to force that property replacement to
> happen again with the newly updated Environment.
>
> If not, then I'm pretty sure you can just manually do replacement on the
> values from getConfigLocations() and set them back using
> setConfigLocation().

Okay, thanks.

A contextConfigLocation with "${idp.home}" will not load because the
property cannot be resolved. With "${idp.home:}" the context will
load, but then the property is replaced with "" so it cannot be
resolved again via setConfigLocations(getConfigLocations()). So, I
guess we would have to use "${idp.home:REPLACE_ME}" or something but
that seems ugly in comparison to just setting idp.home as a system
property.