Best Practice / best design choice considering runtime configurationtype application wide

Question

I'd like to consider the configurationtype of my webapplication (deployment / development) to switch functionality of many modules in my webapplication between live and test behavior.

For example, there are some modules to provide payment services and I need to switch the API configuration between live and sandbox. Id like to decide that based on the webapplications configuration type. Providing for example a method like:

public boolean isRuntimeConfigurationTypeDeployment() {
        return getConfigurationType().equals(RuntimeConfigurationType.DEPLOYMENT);
    }

in my Applications class, which I can call through any wicket Pages. But instead of leaving the responsibility to switch behavior to the wicket components itself, it is probably better to manage these decision centralized. As decisions need to be made in many different Places, I wonder what would be best practice to design this architecture.

Another practical example: A button to manually commit orders to fullfillment center within a Administration frontend

public void onClick(AjaxRequestTarget target) {
                if(getShopAdminApplication().isRuntimeConfigurationTypeDeployment())
                    Export.fullfillment().send();
                else {
                    ExportMock.fullfillment().send();
                }
            }

Answer 1

i would use single service that provides the runtime mode (dev, prod, uat, etc). and another service (spring configuration) that does different kind of ioc depending on the mode. i would avoid checking the mode by components. ioc should be done at startup and then all components should work exactly the same, no matter if it's prod or test. just try to replace implementation of some components for test.

Answer 2

If it's mainly switching services, you could use Google Guice (or some other Dependency Injection framework) to provide these services and have one central point to load modules depending on the current runtime mode in Application.init(). This way your code wouldn't be littered with boilerplate and you couldn't forget this boilerplate...