Comments on: Spring: Many applicationContext.xml > One applicationContext.xml

By: Andrew Sazonov

Andrew Sazonov — Sat, 07 Jun 2008 06:44:16 +0000

Just my 2 cents – suggestion from Mike regarding testing via bean overriding (i.e registering bean in text context using the same name as one in production) will work, but only if context is configured to allows bean definition overriding (there is appropriate setting for that)

By: Mike

Mike — Thu, 29 May 2008 12:45:34 +0000

Max, good points on test datasouces. With a Spring context, you could create a datasource bean with the same name, and then load that test context AFTER the production context, the test context would be used. That way you can keep all the configuration in the application contexts and have them injected.

By: Max Power

Max Power — Wed, 28 May 2008 23:15:03 +0000

Splitting your bean definitions into multiple files is definitely a good practice. However, regarding how your old way of not splitting it up caused the app context to connect to the database reminds me of something I read where I believe the preferred way of coding unit tests is to create the beans programmaticly in the setup methods. This way the tests aren’t tied to configuration files that may be changed, causing the tests to become invalid since they aren’t being run in the same configuration against which they were coded.

By: Adrian Neagomir

Adrian Neagomir — Tue, 27 May 2008 15:14:21 +0000

I use two definition files when doing web applications with Spring: one containing the database access and the service layer while the web related stuff in the configuration file that’s used to configure the DispatcherServlet.

The advantage of having this setup is that I can instantiate a console application that has access to the entire service layer for batch jobs, tests etc. using only the first file without having any dependency to a servlet container.

Using more files one can assemble different application using the same codebase.

By: Matt

Matt — Tue, 27 May 2008 14:55:04 +0000

Another issue we ran into is having several applicationContext.xml on the classpath leads to some very hard to track errors. By giving the file a unique name, you can help avoid these conflicts.

By: Mike

Mike — Mon, 26 May 2008 14:19:18 +0000

Thank you Peter. the 90th percentile states

This is an old habit of mine, a “main index file” that imports everything else. It is a bit cleaner than specifying every file in the web.xml descriptor

and follows up that with an example of how to import many application contexts into a main one.

By: Peter Warhol

Peter Warhol — Sun, 25 May 2008 19:23:43 +0000

I think that was covered recently in the 90th percentile:
http://icoloma.blogspot.com/2008/01/mock-your-spring-config-for-fun-and.html

By: Ashkan

Ashkan — Sat, 24 May 2008 22:53:33 +0000

…
Clearly, working with a smaller xml file is easier than working with one enormous file.
…
And working with as little as possible XML stuff is the utopia so take a look at Guice Mike.

By: cherouvim

cherouvim — Sat, 24 May 2008 22:53:04 +0000

Yep. Many files and imports is how I prefer it as well. Especially those which are deployment related (datasource, mail session details etc).

And I see no problems with that.

By: Jamo Smith

Jamo Smith — Sat, 24 May 2008 22:52:29 +0000

I’ve used a folder called springbeans to hold all my context files. They are module or entity centric:

- user.xml
- project.xml
- hibernate.xml
- security.xml

Tests are able to isolate only 1 or 2 contexts that are required to do the given test.