Naming convention for Spring application context XML

Question

I am deciding on a naming convention for my Spring application context files. I've come across this blog and a couple of tutorials suggesting applicationContext-<name>.xml is the way to go. I'm generally not a find of mixing camel case with dashes/underscores. What are some other naming conventions have you seen?

Edit: I'm also thinking of nesting context files inside the package that pertains to them. For example, my classes/interfaces that relates to ordering would go in context file com/mycompany/order/spring-context.xml . I would have a top-level applicationContext.xml that pulls everything together. Suggestions?

Answer 1

If there were a convention, I would like it to be:

1. files stored in packages (not in default package) to obviate potential naming conflicts and also means I don't have to include the app name in them, it's defined by the package.
2. files named all lower case with a '-' to separate the names

I tend to prefix my spring config files with "spring" makes it more obvious what they are used for, but this is not necessarily mandatory.

But let me say this would work for the way that I've dealt with my spring files, may not work for all contexts.

IMHO applicationContext-<name>.xml is a little verbose (long) and I like all lowercase as it's differentiates them from my java source and (I think) makes them easier to read.

Answer 2

对于Web MVC项目，我倾向于按照职责分解各种上下文文件：

• appname-dao.xml
• appname-servlet.xml
• appname-services.xml
• appname-security.xml

Answer 3

I very much support the applicationContext-<name>.xml convention.

In general <name> refers to the Maven module name in all our projects. So, each module that requires a Spring configuration has its own applicationContext-<name>.xml file. The "execution module" ie the one module that represents the sort of the entry point into the application (WAR, EAR, etc.) has a single applicationContext.xml that only imports all the applicationContext-<name>.xml files.

We use this convention company-wide strictly in all our Maven/Spring projects and it's proved to be extremely simple, clear and efficient.

Answer 4

Either camel case or '-' separated would work fine, as long as you are consistent. I know in our case though we don't put the context files in the same directory as the code, unless the code itself is Spring aware, which in our case it isn't.

We have two cases for this, where we use maven 2, the context file goes in a resource/spring directory, where resource is a sibling of the java source directory. Where maven 1 is used, we simply create a root spring package and put the context there. Both these cases assume 'regular' java code. In the case of Wars, EJB's and OSGi bundles, the files typically reside in the meta-inf directory.

Also, we don't use a top-level application context to 'pull' everything together. We simply create a context with multiple context files. We find this much simpler for testing in different ways, unit tests with mock objects, integration tests with no server and full integration tests deployed to a server. In all these scenarios, simply reconfigure how the context is created instead of having a 'master' context for each scenario.