Announcement Announcement Module
Collapse
No announcement yet.
Override for WebApplicationContext.CONFIG_LOCATION_PARAM Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Override for WebApplicationContext.CONFIG_LOCATION_PARAM

    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.

  • #2
    I can not find CONTEXT_CLASS_PARAM in WebApplicationContext. Are you talking about
    Code:
    ContextLoader.CONTEXT_CLASS_PARAM
    in this case, you can easily overide the default value in your web.xml
    Code:
      <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
          /WEB-INF/dataAccessContext-local.xml  /WEB-INF/applicationContext.xml
        </param-value>
      </context-param>

    Comment


    • #3
      my humblest apologies - I meant
      Code:
      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.

      Comment


      • #4
        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,

        Comment


        • #5
          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.

          Comment

          Working...
          X