18

I want to integrate Spring framework in my project especially into server side.

So, I don't want to put it within WEB-INF folder of war file.

Should I put an applicationContext.xml it into each layer (means each project since divided in distinct projects? (Services, Domain, and DAO)

What is the good practice ?

Improve this question
1

2 Answers 2

Reset to default
26

The Maven file structure may help with this

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.

Improve this answer
2

Is your project split in Maven modules? If so, you can add an extra module just for config files. Lets call it config-module

config-module
      |
      |--> src\main\resources\config\spring\applicationContex.xml
      |--> src\main\resources\config\properties\application.properties
      |--> pom.xml

Such configuration is a suggestion. Set up your own file set Package it like a JAR and add this module as dependency of any other module (web, ear's lib, another jar).

You will have access to config-module resources (xml, properties, etc.) because they are in the classpath.

web-module's pom

<dependency>
    <groupId>com.myproject.group</groupId>
    <artifactId>config-module</artifactId>
</dependency>

Then use import statements from external Spring context files. For example

<import resource="classpath*:com/package/subpackage/**/config/applicationContext.xml" />
Improve this answer
2
  • This was a great idea! I took liberty of adding a little extra because your example "import resource" was not working for me......I'm still learning the "filtering" of the import statement (based on the full package name)... and I did not work that hiccup (for future readers) to distract from this great idea and answer. Thanks Laiv !
    – granadaCoder
    Feb 23, 2019 at 10:53
  • One of the reasons your "what I think should work" import may be failing is because of this bug : github.com/spring-projects/spring-framework/issues/16017
    – granadaCoder
    Feb 24, 2019 at 8:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.