Shared properties within application context

[milosh]

Here is the concrete problem I faced in writing test cases within a team of couple of coders:
Each of coder writes test cases against their own classes. Each test case has certain configuration associated with it. Most of the configuration can be shared between coders but there are certain properties, which are specific for each coder. By shared properites I assumed ones, which can be set within test cases and run on each of coder's machines. Example of non-shared properties would be different connection string (for database) for each coder. Each of us want to use separate database since we do not want to intersect with each others data while writing test cases or running them. I know that one of the advices ("J2EE Development without EJB") state that unit tests should not use external resources. I could agree on that. But what about integration tests? Some of the coders want to write some of those tests also. Performance tests falls into same category. For those tests external resources are important.

Second problem was web.xml file or Spring application context shared between coders and QA. Both contain set of properties, which potentially have different values for each coder and each QA.

Question is: where to put such kind of overlaps? where to keep safe copy? source control? Some of them can be pretty big and I do not want to write them again in case of what ever failure on my local machine. Also I would like to download complete source tree from source control on my home machine (when I work from home) and be set to go almost instantly from the point where I stopped in office. Particular interesting case is this "home case". Within the office all coders could share one development server with Oracle instance and with separate databases. At home I need to have local Oracle instance in order to verify tests before checking-in modification into source control.

One solution which I envisaged in my coding strategy is to use variables in Spring application context files in place of overlapping (non-shared) properties. Each coder would keep his set of properties for his own test cases. I also wanted checked-in those properties files. They will reside in test part of source tree and I didn't see as big problem to have "personalized" files in source control managed in that fashion. Test cases are rarelly shipped with commercial application, so no harm to have them as part of test tree.

I am sorry for a bit long post, but I had couple of long debates within my team on the subject and I would like to hear some Spring experiances.

[Rod Johnson]

One solution which I envisaged in my coding strategy is to use variables in Spring application context files in place of overlapping (non-shared) properties. Each coder would keep his set of properties for his own test cases

Have you looked at PropertyPlaceholderConfigurer or PropertyOverrideConfigurer? This sounds like what you want. You then let each developer manage his own properties file instance, without changing the XML.

[milosh]

PropertyPlaceholderConfigurer is the exact thing what I am using in order not to duplicate complete configuration files between coders rather properties which overlap. The issue is where is the best location to keep these separate files for each coder and how the production application context should look like? With placeholders or without.

Regards,

[ojolly]

It doesn't reply precisely to your question but here how we manage various environment configuration at work.
We define several files with database info such as hibernate.properties.development, hibernate.properties.validation, hibernate.properties.production, etc.. and we use a symbolic link (or a mere copy on non posix compliant OSes) to make hibernate.properties points to one of those. We add a .cvsignore on hibernate.properties to make sure that the choice made on every machine / location for this file context isn't synchronized with the cvs repository in any way.
In fact, when we choose to build a .war, we're giving the "extension" as parameter and for all files configured that way we copy/link from realfile.param to realfile and have fixed build script.
Eventually, you can use ant filter copy mechanism to introduce variables defined in one of those properties into arbitrary files.

HTH

Olivier

[milosh]

I using nearly the same approach in my private programming since I am using CVS and .cvsignore is an option. Also I am coding on Linux.

At work is a bit problem, since all development is done on Win XP and source control is StarTeam (which is very bad in my opinion). Win XP is platform because of some maintanence of previos software version written in C++ and .NET.

Similar solution for config files is needed for Spring.NET, since I would like to use it on client side also. Our client applications are written in .NET and server is written in Java.

[rob_from_ca]

My general technique for this type of configuration information has become to first push all of the environment specific configuration into a small include file via whatever mechanisms the thing supports, XML includes, property configurer, sourcing in shell scripts, whatever. Then turn those include files into templates (I use an ant/velocity preprocessor called vpp (http://vpp.sourceforge.net), and maintain one property file per environment that populates those include files. I'm sure there's some fairly simple .NET templating language.

That way you get the mechanism to create all of your configurations (be they hibernate configs, app-server config files, or your own environment-specific property files). The right environment file is picked up to populate the configuration at deployment time. The properties are all populated via ant, so developers can override any property, anywhere in the configuration by just dropping a replacement for it into a local.properties file that lives outside of source control.