We use this model at work:
Production config.properties:
serviceClass=com.mycompany.LiveService
Development config.properties:
serviceClass=com.mycompany.MockService
spring.xml:
<bean id="service" class="${serviceClass}"/>
(with the appropriate property configurer)
Try this one too. I like it better, because you don't end up putting class names in the configuration, which I think should speak at a different level of abstraction.
Production config.properties:
environment=production
Dev config.properties:
environment=development
<bean id="service" class="com.mycompany.ServiceSelector">
<property name="environment" value="${environment}"/>
<property name="liveService" ref="liveService"/>
<property name="mockService" ref="mockService"/>
</bean>
// a proxy that decides on the class to "let through" based on the environment
class ServiceSelector {
public void setLiveService(Service liveService) {
this.liveService = liveService;
updateCurrentService();
}
public void setMockService(Service mockService) {
this.mockService = mockService;
updateCurrentService();
}
public void setEnvironment(Environment environment) {
this.environment = environment;
updateCurrentService();
}
private void updateCurrentService() {
if (environment == null) {
currentService = null;
return;
}
switch (environment) {
case production:
currentService = liveService;
break;
case development:
currentService = mockService;
break;
default:
throw new IllegalStateException();
}
}
}
If you have a large enough number of services in this situation, you can put all such services under a facade and implement one facade selector instead of many service selectors.
Another variation is to throw away the configuration file and provide the environment flag in the environment itself. It could be a JVM property defined with -Dname=value
when the JVM is invoked, etc.