Development / Testing / Deployment

[mlconnor]

Does anyone have any best practices with respec to creating configuration files for Development / Testing / Deployment?

The problem is that the config files we have are relatively large and if we have different files for dev, test, and deploy then it gets to be a nightmare to manage those. If I add something to the dev config file then I need to update test and deployment configs too. And then the testing and deployment people need to merge their changes back with my additions.

It seems as though there should be some kind of conditional statement or the ability to import fragments. For example...

   <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">  
        <property name="dataSource" ref="dataSource"/>
        <property name="mappingResources">
            <list>
                <value>com/foo/platform/content/Content.hbm.xml</value>
                <value>com/foo/platform/rating/Rating.hbm.xml</value>
                <value>com/foo/platform/tracking/Tracking.hbm.xml</value>
                <value>com/foo/platform/services/filestore/local/FileInfo.Hbm.xml</value>
                <value>com/foo/platform/security/beans/Role.hbm.xml</value>
                <value>com/foo/platform/security/beans/User.hbm.xml</value>
                <value>test/com/foo/platform/rating/examples/TestStuff.hbm.xml</value>
            </list>
        </property>
        ...

My problem is the TestStuff.hbm.xml should only be there for Unit testing and not production. Do I have to duplicate the ENTIRE file just to remove that one element ?

[jbetancourt]

This has been discussed here on the forums. Some good suggestions were made and may have made it into the Jira issue tracking system.

One thing you could do is use Spring's import capability. See http://static.springframework.org/sp...context-import

Also, you can use hierarchical contexts that easily override bean definitions.

In the past there was discussion of adding conditional stuff to context files, sort of like Ant's "if" or "unless" on tasks, but this did not go anywhere, for obvious reasons.

[mlconnor]

Thanks for the heads up jbetancourt. The issue with imports is that you can't simply import a fragment. You have to import at least an entire bean. So if you include 50 hibernate mapping files and you have an extra 5 for testing, then it needs to be replicated.

One trick I've discovered I can do is use the replace function in ant.

<stuff i always want>
<!--BEGINTEST <stuff i want for test/> <!--ENDTEST-->

I can

replace("<!--BEGINTEST", "<!--BEGINTEST-->") and
replace("ENDTEST-->", "<!--ENDTEST-->")

yielding...

<!--BEGINTEST--> <stuff i want for test> <!--ENDTEST-->

which in essence adds the test stuff into the spring file.

I can then undo the effects of this after I run the tests. This is a little hackish but better than the alternative...

[jbetancourt]

Interesting. After all these years with Ant, I never noticed the Replace task. I've used the external xmlTask for prior non-spring projects instead. See: http://www.oopsconsultancy.com/software/xmltask.html

[mlconnor]

XMLTask looks cool. I wish it were part of the standard Ant build as it would come in handy for a lot of different stuff. They do have an xslt task though that may do some of it...

[devijvers]

Ant may be cool, but having to run an Ant script in order to run integration tests is not considered efficient anymore.

A more interesting approach is to factor out those bean definitions that differ between development/preproduction/production into separate xml files. I advise against using the import tag in this scenario. A better approach is to list the xml file you want to load in your integration tests and web.xml file.

Another approach that can be combined with my previous suggestion is to place configurational values in properties files.

[Rod Johnson]

Agreed. Typically you'll end up with only one or two files (for example, covering data source and platform transaction manager) that differ between environments, and they will cover only a few bean definitions. Other differences you can address using properties files.

This means that you get to validate your configuration also.