Configuration File Strategy

[Tom Whitner]

I have been working on my first “real” spring-based prototype. So far I am pleased and optimistic. However, I can’t help but get the uncomfortable feeling that I will end up with one enormous configuration file and no code. In my small project of a dozen or so classes, nearly every one of them has configuration associated. This is not necessarily a bad thing, but I am wondering if there has been any thought given to how one might organize this. One beautiful thing about development languages is that they allow for physical and logical partitioning of assets (i.e. namespaces, assemblies, classes, etc.). Is the same concept possible with Spring? For instance, I might want to have a configuration file for each assembly rather than one huge one.

[Mark Pollack]

Hi Tom,

There are a few options currently available, hopefully they will meet your needs.

The configuration from several resource locations can be passed as a list to a "FileSystemXmlApplicationContext" constructor. This will create a single (not heirarchical) ApplicationContext from the various pieces. You can have a config file for each assembly using this approach.

There is also the idea of hierarchical contexts, in which a parent context is specified for a list of child contexts. Object definitions are searched for by traversing up the hierarchy.

In the Spring.Java world I've seen the "flat" approach used to provide different configuration files for different layers in the application, the data access layer, the business services layer etc. The heirarchy approach is useful for a sort of 'subclassing' style of configuration. There are also some naming conventions for servlets so that each can get its own unique xml configuration file.

Let us know what you think about these approaches for managing configuration information - maybe you are thinking of some other means. Thanks for the continued feedback!

Cheers,
Mark

[Aleks Seovic]

In addition to what Mark described there is also include element that you can use to merge multple configuration files into one.

For example, in ASP.Net app I'm building right now, I have main Spring config file called Objects.xml. However, this file has very few definitions itself, it mostly contains include tags referencing other config files:

<include resource="Pages.xml"/>

<include resource="Navigation.xml"/>

...

This way I can manage different types of object definitions in different files, using any type of separation I find appropriate.

Regards,

Aleks

[Mark Pollack]

Doh! I forgot that one! :oops:

[Tom Whitner]

Thanks, now I can see how I might implement a solution with multiple configuration files. However, this was really a two part question. As Aleks stated:

This way I can manage different types of object definitions in different files, using any type of separation I find appropriate.

The second, and I think harder part of the question, is "What's appropriate?" I know there is no one answer, but just as there are now many discussion on how to break down one's namespaces, I figured it might be worthwhile to discuss how one breaks down their configuration into manageable chunks.

[Aleks Seovic]

I guess that's really a matter of personal preference, team size, version control system used, and for the most part, nature and size of the application itself.

I tend to prefer number of smaller files instead of few large ones, but I guess for the most part I just rely on my gut feel to decide what goes where. If I realize later that something should be moved, or that new file should be created, it's easy enough to do.

If you have many people on the project and are using VCS with exclusive locking, such as VSS, it is probably a good idea to make config files more granular in order to reduce contention. I generally don't like this "tool driven" organization of my files and prefer to replace the tool instead, but unfortunately, that's not always possible.

I know I didn't really answer your question, but it was a trick question to some extent :) I simply don't believe that there is one-size-fits-all answer to it because there are so many factors that need to be taken into consideration. Different people will put different weight on each of the factors for the same type of application, and same person is likely to put different weight on them when building different applications.

Best we can do is provide features for users to make their config files more manageable and hope that they understand them and use them appropriately for their set of circumstances, applying basic common sense along the way.

Now, this approach will not fly in a more structured environment where everything needs to be documented up front as an SOP and those are later used by developers working on the project. Under those circumstances, I would definitely encourage separate SOPs development for web applications, desktop applications, windows services, etc. Some of the elements will be the same, but it is very unlikely that same exact approach will work for each of these, architecturally very different applications.

Regards,

Aleks