tags:

views:

816

answers:

3

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?

+1  A: 

For a Web MVC project, I tend to break down the various context files along lines of responsibility:

  • appname-dao.xml
  • appname-servlet.xml
  • appname-services.xml
  • appname-security.xml
matt b
+1  A: 

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.

Robin
+1  A: 

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.

Michael Wiles