Using System property placeholders in "contextConfigLocation" fails in 2.5.2 [SPR-4568] #9245
Description
Paul Nyheim opened SPR-4568 and commented
We have been using an undocumented feature of the ContextLoader (and ContextLoaderListener) where System properties in the "contextConfigLocation" in web.xml would be resolved autmatically.
i.e.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:/dao-provider-${deployment.environment}.xml
</param-value>
</context-param>
This worked like a charm up to version 2.5.1, but in 2.5.2 there was a change in the ContextLoader which changed the behaviour of the context initialization.
Since this has been an undocumented feature - I am not sure whether this is actually a real bug, but we will still depend on this feature. Our current workaround is to extend ContextLoader and ContextLoaderListener, and provide an implementation of the customizeContext method where we can resolve the System properties ourselves.
The only difference I can find is that in 2.5.1 the ContextLoader.createWebApplicationContext() method would invoke the ConfigurableWebApplicationContext.setConfigLocations() method with the configLocations from web.xml. In 2.5.2 this was changed to invoke the ConfigurableWebApplicationContext.setConfigLocation() (notice the plural/singural difference here).
Tracing it down to AbstractRefreshableConfigApplicationContext I find that the outcome of the setConfigLocation and setConfigLocations respectively is in deed different if the input contains System.property placeholders.
Affects: 2.5.2
Attachments:
- testcase.zip (1.77 kB)
1 votes, 1 watchers