Where do you keeep your configuration?

[nlif]

Hi,

I'm trying to come up with techniques and best-practices regarding the location of configuration files, and by that I mean two different kinds: spring context XML files, and Java .properties files that contain environment-specific data, such as the server addresses and passwords.

With regards to environment-specific properties, my main concern is that if these files are bundled in the WAR file, then each installation overrides the local copies, which most likely have been modified (in fact, in some cases, it doesn't even make any sense that the application will come with defaults, for example, database URL). Spring's PropertyPlaceholderConfigurer looks for the files somewhere in the classpath, or anywhere in the file-system. My question is, where is it best to put them? somewhere under the web-server, or someplace else entirely? Do people write their own propertyConfigurer implementations that load properties via other mechanisms?

With regards to Spring context files: so far I used to place them either at the root of my source folder (so they're in the root of my classpath at deployment), or under WEB-INF if it's a web-application. However, in many cases I find it better to break large context files in to smaller ones, grouped by topic (e.g. web-tier, data-access tier, acegi etc). Is it a good idea to put them with their respective classes, that is, with the source-code, in the respective package? or would it make it harder to manage, since we end up with dozens of XMLs all over the place?

I'd be happy to hear what other people are doing.

Thanks,
Naaman

[Andreas Senft]

Concerning the application context files I also tend to place them in a root folder as you described. I find them easier to lookup than when I hide them within the package structure.
As of splitting up a context into several files: I do that also for larger contexts, so having someting like business-context.xml, security-context.xml, dao-context.xml etc. If the application is packed into one deployment unit (e.g. a WAR) then I also keep the context files in one place together.

Concerning properties files: I tend to discern from configurations to be made by the developer an those to be made administratively. The former are part of the context xml files while I extract the latter using a property configurer. The properties files should be looked up using relative paths to avoid specifying absolute paths. Sometimes that means to tweak classpath settings.

Just my 2 cents,
Andreas

[nlif]

Thanks, Andreas.

Concerning the application context files I also tend to place them in a root folder as you described. I find them easier to lookup than when I hide them within the package structure.
As of splitting up a context into several files: I do that also for larger contexts, so having someting like business-context.xml, security-context.xml, dao-context.xml etc. If the application is packed into one deployment unit (e.g. a WAR) then I also keep the context files in one place together.

Let me elaborate on my reasons: I have reusable components that are used across projects. These are bundled as JARs and are added to the project's classpath. It makes sense for me to reuse the Spring context files along with the classes, so the XMLs will be in the JAR. Thus, I can reuse the code together with the Spring configuration (after all, Spring context XMLs may be viewed as non-Java source-code).

Concerning properties files: I tend to discern from configurations to be made by the developer an those to be made administratively. The former are part of the context xml files while I extract the latter using a property configurer. The properties files should be looked up using relative paths to avoid specifying absolute paths. Sometimes that means to tweak classpath settings.

What do you mean by "tweak classpath settings"?
When you say you use relative paths, do you mean path that is outside of the WAR scope?

Naaman

[Andreas Senft]

I have reusable components that are used across projects. These are bundled as JARs and are added to the project's classpath. It makes sense for me to reuse the Spring context files along with the classes, so the XMLs will be in the JAR.

Ok. That case sounds reasonable. So you just take the jar and be done.

What do you mean by "tweak classpath settings"?
When you say you use relative paths, do you mean path that is outside of the WAR scope?

I once had the case with an EAR (but it's conceptually the same). I didn't want to lookup the configuration file from within the EAR as I wanted to change its contents without rebuilding the EAR each time. So I added a relative class-path location inside the manifes of the jar file in question. In order to allow the lookup the relative path outside the ear, I told the app server to add the root folder of that relative path to the classpath. In effect I modified the app-server's start script and added a classpath entry.

Regards,
Andreas