Override for WebApplicationContext.CONFIG_LOCATION_PARAM

[gcosgrave]

Hi,

I would like to have a system property (or some other external means) to override the WebApplicationContext.CONFIG_LOCATION_PARAM
so I can have multiple Spring configurations for one Web Application.

The reason I would like this is that I want to integration test my web application without a database using stubs for my DAO's. I would have two context parameters:
contextConfigLocation=
/WEB-INF/applicationContext.xml classpath:dao.xml
testContextConfigLocation=
/WEB-INF/applicationContext.xml classpath:stubdao.xml

I feel this may be generally useful and would like to see it included in Spring. Does anyone else agree or is there already a way of achieving what I need?

Regards,
Gordon.

[irbouho]

I can not find CONTEXT_CLASS_PARAM in WebApplicationContext. Are you talking about

ContextLoader.CONTEXT_CLASS_PARAM

in this case, you can easily overide the default value in your web.xml

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/dataAccessContext-local.xml /WEB-INF/applicationContext.xml
</param-value>
</context-param>

[gcosgrave]

my humblest apologies - I meant org.springframework.web.context.ContextLoader

The whole point is NOT to override the contextConfigLocation parameter in web.xml as I don't want to have to keep changing it depending on what mode I am working in - instead I will have two server instances running exactly the same application with different Spring configurations.

[Colin Sampaleanu]

Well, the contextConfigLocation _is_ an override.

I don't see this as fundamentally different than any number of other things that can come from a file, and it's not an option to make all of them settable as system properties too. Additionally, the system property approach has a big problem too since then you can't have multiple web-apps running in that one appserver, and have different settings for each.

What I would recommend instead, is to just use a shell script of some sort that allows you to toggle it one way vs. another, via a regexp search/replace. The default build would be for production, and for testing you would reconfigure it.

Regards,

[arsenjew]

In fact, elegant switching between real and mock implementations can be achieved rather easily using Ant's <filter> and <switch> tasks: Add a property deployment.mode to your build script and use different filters for replacing the context parameter @contextConfigLocation@ with the appropriate path in your web.xml, based on whether the value of ${deployment.mode} is "mock" or "real". The build process is where to do this, not the application itself, so this is nothing the framwork should care about or provide means for.