Question

We have multiple projects, and there are spring configuration XMLs in all of them. We’re contemplating 2 options:

A) Loading the spring files from the classpath, by using import "classpath:a.xml". In this option our springjunit4classrunner and our main console application both happily find the files. However, when you need to change or inspect some XML, it’s well hidden in some obscure jar.

B) Creating a “conf” folder, and by using some maven magic gathering all the XML files from all the projects there. This is good for the main application, but the unittests don’t like this setting, as obviously we don’t build the “conf” folder before running unittests, and they fail to find the dependent projects XMLS…

(This is a spring re-take on Is it bad practice to include properties/configuaration files within jars?)

Answer 1

In the past, I’ve gone with <import resource="classpath*:beans.xml"/> or similar, i.e. import every beans.xml file the classloader can find in the root of the classpath. In turn, those beans.xml files import their own specific config files as required.

It requires discipline, so that you don’t get big spider webs of Spring configs, but if you keep it simple, then it makes integration very easy, so that you don’t need to maintain complex lists of config file imports, and the build process stays simple also.

It’s interesting that you mention that prior question, because I don’t consider Spring beans files to be “configuration”. Rather, they’re part of the application – they cannot and should not be separated from the Java code, because they’re intimately coupled with it.

If those beans files require genuine configuration, e.g. from a properties file, then yes, those probably should be kept separate.