Distinct properties in Mule runtime environments

There’s several ways of propagating properties in Mule deployments based on the environment Mule is running in. Typically we find our projects having at least a Dev, Text and Prod environment, sometimes you may have more like Stage, Perf and others. The property approach follows the same pattern no matter how many differing environments you may need to support.

Property environments may come in through the OS environment or through the runtime wrapper.conf file. The wrapper.conf properties are available to all Mule projects deployed in the runtime environment.

To use a system environment variable to read your property file based on the environment, you might use an approach similar to the one shown below.

<!-- 
  Use environment variable to specify the runtime property file to use
  For DEV, TEST, PROD your OS env would configure in a similar fashion
    export RUNTIME_ENV=DEV

  and, your src/main/resources would contain:
    config.DEV.properties
    config.TEST.properties
    config.PROD.properties
-->
<context:property-placeholder location="config.${RUNTIME_ENV}.properties" />

You would follow a similary approach if using a YAML rpoperty files instead of a flat name/value property file. In another post i’ll describe how private values are protected in the property file using secure property placeholders.

There are time where you might prefer generating project property files at build time. In this case you would implement profiles in your Maven pom.xml file similar to the example below.

<!-- Add your nexus repo -->
<distributionManagement>
<repository>
	<id>cms-nexus</id>
	<url>https://nexus.com/nexus/repository/cms-maven2/</url>
</repository>
</distributionManagement>

<profiles>

  <profile>
	<id>dev</id>
	<properties>
	  <profile-id>DEV</profile-id>
	</properties>
	<build>
	<plugins>
	  <plugin>
		<artifactId>maven-antrun-plugin</artifactId>
		<executions>
		  <execution>
			<phase>test</phase>
				<goals>
				  <goal>run</goal>
				</goals>
				<configuration>
				  <tasks>
					<delete file="${project.build.outputDirectory}/config.DEV.properties" />
					<copy file="src/test/resources/config.DEV.properties"
						tofile="${project.build.outputDirectory}/mulish.properties" />
					<copy file="src/test/resources/config.DEV.properties"
						tofile="${project.build.outputDirectory}/consumer.properties" />
				  </tasks>
				</configuration>
		  </execution>
		</executions>
	  </plugin>
	</plugins>
	</build>

  </profile>
  <profile>
	<id>testenv</id>
	<properties>
		<profile-id>testenv</profile-id>
	</properties>

	   ...
	   
	</build>
  </profile>
</profiles>

   ...

In the example above, when maven build the project archive you would specify the environment you would like to have the property file configured for. If building for DEV you would do something like the following:

# the -P flag specifies the Profile
mvn package -P DEV

The maven profile will delete the default property file and copy the property file for the runtime environment into it’s place. The property files for each environment in this example are kept in the folder src/test/resources. The reason for this is to prevent property files from other environments from being copied into the runtime package file.

I hope you’ve enjoyed this POST on property management in Mule and look forward to your feedback.