redefine spring.net object in multiple configuration files

Question

I am setting up my xml configuration files for my asp.net web application using spring.net IOC dependency injection. I referenced each of my config files in the web.config. A sample of setting in spring.net configuration file (settings.xml) is:

<object id="obj1"
      type="NS.Common.Cache.Class, NS.Common"
      singleton="true"
      init-method="Initialize"
      destroy-method="Dispose">
  <property name="Name" value="My Name" />
</object>

This all works fine.

Now I install my web application in multiple environments so I am creating a spring.net config file for environment eg. dev, qa, prod.

So when installing the application, the applicable environment spring file is referenced in the web.config. This is part of an automated installer.

Within the qa environment file, I want to redefine the object above "obj1" to:

<object id="obj1"
    type="NS.Common.Cache.Class2, NS.Common"
    singleton="true"
    init-method="Initialize"
    destroy-method="Dispose">
  <property name="Name" value="My New Name" />
</object>

However as this is automated (adding the reference to the environment file), the settings.xml file is not changed.

And now referencing 2 files with a defined object with the same id - this causes major problems as run time errors will occur.

Is there any way that I can include in the qa.xml and flag or the like to highlight this object definition overrides any other defined objects in any other xml file with the same object id?

Answer 1

You can load two identical ids and the last id will "override" the first listed object (before creation, they must be in different files by having them referenced within the context definition).

<context ...>
   <resource ... /> <!-- put your 3rd-party (read-only config here) -->
   <resource ... /> <!-- put your override ids here -->
</context>

Because of this default behaviour it is a good practice to include your context ressources in the order beginning with "global meaning" (e.g. 3rd party configs you want to reuse) down to "local meaning" (having app.config's as last entry).