Best Practices for Dev/Prod strategy config separation

[shaine]

Hi there.

Could someone please point me in a direction with regards to using different dataaccess strategies depending on if in dev or production.

in dev we might want to read all contetn from static xml files, while in prod we will want to read from a content server.

having many manager using different DAO's can lead to forgetting to change in all places.

Are there best practices for avoiding the below

	
<bean id="contentDao" class="za.co.domainname.ucm.UcmContentDao" lazy-init="true" />
	
<bean id="contentDao_" class="za.co.domainname.dao.dummy.DummyContentDao" lazy-init="true" />	
	
<bean id="contentManager" class="za.co.domainname.manager.ContentManager">
	<property name="contentDao" ref="contentDao" />
</bean>

[pzoio]

With a Impala this would be very simple because you could simply have different modules for your DAO layer for dev and production, and load these or not as required.

For a Spring-only approach, move all of your test DAOs and production DAOs into two separate spring config files. Each of these files will contain the respective DAO definitions, ie. contentDAO, etc.

For your test configuration, only include the test DAO config file in your list of spring config files, and similarly for production.

Still involves a bit of manual editing/build tweaking, but seems like a cleaner approach.

Phil Zoio
Impala - simple dynamic modules for Spring
http://www.impalaframework.org/
http://impalablog.blogspot.com/

[shaine]

thanks Phil

yeah, I think the approach of having 2 separate config files for test/dev DAO's will be the simplest, so will use this method for now

it is often not easy to decide to separate your beans based on tiers or on functionality, ie all DAO's together vs all product related beans together.

[dkarr]

I'm not sure if this will work, but you could have separate config files for the environment-specific beans, as described earlier, but put the environment name in the config file name in a standard pattern, then specify the environment-specific config file name in the "top" config file like "classpath:config-${env}.xml".

Alternatively, don't package the environment-specific config file in the deployment package at all (or package a "default" one), but have the "top" config file specify it in the classpath, and have your environment specify a classpath dir that is outside of the deployment package. In each environment (test, integration, prod, etc.), put the environment-specific config in that directory. Make sure that directory is earlier in the classpath than the deployment package.

[shaine]

I forgot to mention, this is a spring mvc servlet.