Broadleaf also has built-in support for managing configuration values that may change based on your deployment environment (i.e. development, test, production, etc...). This configuration has changed slightly for 2.0, which this documentation reflects.
Property files are merged by the RuntimeEnvironmentPropertiesConfigurer and then forwarded onto Spring for use in your application. The priority hierarchy for this merge is as follows, with latter properties overriding earlier ones. Note that we are using
development as the environment for these examples -- it would obviously change if the current environment was different.
common-shared.propertiesin the core project
development-shared.propertiesin the core project
common.propertiesfrom the specific application (either site or admin)
development.propertiesfrom the specific application (either site or admin)
This powerful configuration will allow you to share various attributes amongst environments and override them where necessary.
Furthermore, if you have local developer properties or other properties that you do not wish to commit to version control, you can specify file paths via the
property-override JVM runtime arguments.
Note - All of these properties files should appear in the
src/main/resources/runtime-environment/directories for their respective project. The Broadleaf
RuntimeEnvironmentPropertiesConfigurer(set up in the next sections) is configured by default to look for properties files in the
runtime-propertiesfolder on the classpath.
Most users will simply need to add a reference to the
blConfiguration bean in their
applicationContext.xml file (and
applicationContext-admin.xml), like this:
<bean id="blConfiguration" class="org.broadleafcommerce.common.config.RuntimeEnvironmentPropertiesConfigurer" />
This will set up the appropriate merging of properties between your different applications / environments as well as defaults provided by Broadleaf. The default environments provided by Broadleaf are:
Note - to specify an environment, a system property entitled
runtime.environmentshould be set. This is normally accomplished via a Java startup parameter for your application container (i.e.
These environments will suffice for the majority of users. However, if you would prefer to use a different set of environments, you would simply configure the
blConfiguration bean like this:
<bean id="blConfiguration" class="org.broadleafcommerce.common.config.RuntimeEnvironmentPropertiesConfigurer"> <property name="environments"> <set> <value>myenv1</value> <value>myenv2</value> </set> </property> <property name="defaultEnvironment" value="myenv1"/> </bean>
Note: If you are customizing the
blConfigurationbean in any way, you will need to define it in both
applicationContext-servlet.xml(and again for the admin applicaation). This is a known issue in the servlet configuration in Spring.
Additionally, it's possible to specify computer specific overrides for both the application level and shared level. This is controlled by the following two JVM args:
In this scenario, regardless of the environment that the application starts up under, any properties specified in computer1-shared.properties would overwrite properties from the WAR. Additionally, you could further overwrite properties with computer1-admin.properties. For example, a common use case for this could be a developer that wanted to use MySQL for their local environment. They could create developername-shared.properties, and specify the appropriate MySQL dialects in that file. Another use case would be the ability to maintain secret application keys directly on the application servers and not checked into source control.