1 Answer
1

In essence the Spring configuration files (that can have any name by the way, not just the generic applicationContext.xml) are treated as classpath resources and filed under src/main/resources. During the build process, these are then copied into the WEB-INF/classes directory which is the normal place for these files to end up.

Variations include an additional spring directory (e.g. src/main/resources/spring) to separate the Spring contexts from other resources dedicated to application frameworks. You may wish to split the application contexts into dedicated layers such as:

example-servlet.xml
example-data.xml
example-security.xml

and so on.

What about different environments like dev/test/production?

Typically, your Spring configuration should pick up the environment configuration from its, ahem, environment. Usually this means using JNDI, JDBC, environment variables or external properties files to provide the necessary configuration. I list those in order of preference since JNDI is generally easier to administer than external properties files in a controlled production cluster.

In the case of integration testing you may need to use a "test-only" Spring configuration file. This would contain special contexts that use test beans or configuration. These would be present under src/test/resources and may have a test- prefix to make sure that developers are aware of their purpose. A typical use would be to provide a non-JNDI DataSource perhaps targeting a HSQLDB database during the build automated tests and would be referenced within the test case.

However, in general the majority of your Spring context files should not need specialised modification as they move between tiers. It should be the case that the same build artifact (e.g. WAR file) is used in dev/test/production just with different credentials.