Mule - mule-deploy-override.properties, is this possible?

Question 1

I suggest you set up as follows:

Use no default properties
Keep properties for unit testing in the test resources
Keep properties for test, stage and production environments as files in external directories.

This way, you can update properties without rebuilding the project (touching the anchor file is enough). Also, potentially sensitive properties can be kept secret.

Another approach would be to use the Constretto project and have all properties in the same file, if that is acceptable.

One of my colleagues has created a configuration project on github for a setup with support for environment-based properties files on Mule ESB. Get some inspiration there, or just use the project as-is.

Question 2

You should use property placeholder to bind the external properties set into default mule-app.properties. the external properties set would be environment specific like dev, test, stage and prod. Only the reference in default mule-app.properties would automatically overrides all the properties into the default one.

For more details read https://docs.mulesoft.com/mule-user-guide/v/3.7/configuring-properties#sts=Property Placeholders

Question 3

we have to set environment variable and we can use like mule.env = dev and in your application or project set the multiple properties file based on your environment like

test-dev.properties
test-qa.properties
test-prod.properties

and we use override properties to specifying the exact path .

ex :

<property-placeholder name="Property_Placeholder" location="test-${mule.env}.properties,file:///opt/app/test/app-config/test-override.properties"/>

Question 4

Might not be exactly what you are looking for, but this is how do it.

First of all, in the project under src/main/resources, create a new Untitled text file called, "test.properties".

In test.properties you can add the properties you want to use in the project.

Create a new Mule Configuration File called "test-override-properties.xml"

Open up the XML view of the new flow and add the following.

You can specify any directory for the override properties file to be in. In the example i used the mule home directory/conf/ , and created a folder called properties, and a text file called test-override.properties.

You can now add properties to test.properties, and once the project is deployed, you can override those properties using the test-override.properties file you created.

Hope it helps.

Question 5

Our solution for this is to set an environment variable on each server with the environment name. The environment variable is "mule.env". So for the QA environment, mule.env=qa. Then I have a property placeholder in my project like this:

 <context:property-placeholder location="${mule.env}.properties"/>

I then have the following files in src/main/resources to store environment-specific properties:

qa.properties
staging.properties
production.properties

Question 6

First thing is Yes you can have deploy.properties but as many people suggested its good to have environment specific and business specific properties separately. As part of my experience we used three types like business, application and system and this properties are based on the environment.

Question 7

You can use the over ride properties... best way it sue the environment variable and we are using same thing as part of our project.

Question 8

I have a similar concern.

I solved it this way -

Environment: Mulestudio, Maven (command based) and Cloudhub

Declared {mule.env} property in my context placeholder

<context:property-placeholder location="${mule.env}.properties"/>

for development environment, the mule.env=dev and so and so forth for your test and prod

Then added profiles to the Maven pom.xml file

<profiles> <profile> <id>test</id> <properties> <files.to.exclude.1>prod.properties</files.to.exclude.1> <files.to.exclude.2>dev.properties</files.to.exclude.2> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>prod</id> <properties> <files.to.exclude.1>dev.properties</files.to.exclude.1> <files.to.exclude>test.properties</files.to.exclude> </properties> </profile> <profile> <id>dev</id> <properties> <files.to.exclude.1>test.properties</files.to.exclude.1> <files.to.exclude.2>prod.properties</files.to.exclude.2> </properties> </profile> </profiles>
in the build section added the following -

<resources> <resource> <directory>src/main/resources/</directory> <excludes> <exclude>${files.to.exclude.1}</exclude> <exclude>${files.to.exclude.2}</exclude> </excludes> </resource> </resources>
finally run my maven passing the profile on the command line, like -

mvn clean package -Pdev, where dev is the profile id

This will exclude the prod and test properties file as defined in the exclude property.

Its highly configurable here.

Hope this helps

Question 9

To set dynamically specify property files you should do this:

Define an environment property value in mule-app.properties first open mule-app.properties. In this file you can define a property called for example env and set it to dev. This is your first property description, then save the file.

Then use the environment property in the Property Placeholder. To do that return to global.xml, and edit the properties of the placeholder. In the Global Element Properties dialog box, change the location to apessentials- ${env}.properties and click OK.

After that locate the mmc-runtime-bundle-3.7. and, navigate to the mule-enterprise-3.7.X/conf folder. Once there open wrapper.conf in a text editor.

In this file locate the last numbered wrapper.java.additional instruction near the top of the file. Beneath it, create a new instruction with the number incremented by one that passes an argument called env equal to dev to the runtime when it starts.

wrapper.java.additional.15=-‐Denv=dev Note: Be sure to use the correct number. This number may be different than shown here for your version of the runtime.

Hope this help you.

Question 10

We need to maintain two property files say mule-prod.properties and emphasized textmule-dev.properties.

Then we need to configure property placeholder component as

<"context:property-placeholder location="${mule.env}.properties"/>

and your mule-app.properties file you need to configure a property as shown below

mule.env= dev (or prod)

During deployment depending on the mule.env value, mule loads corresponding property file.

Question 11

Mule’s deployment descriptor is a properties file, mule-deploy.properties, that controls how a Mule application should be deployed. A typical application, however, would rarely need to use any of the configuration properties available in the file, relying instead on defaults.

An example of the contents of a simple deployment configuration file:

redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=sfdc-outbound-messaging-example.xml

Question 12

use Spring specific configuration for environment property:

<"context:property-placeholder location="${mule.env}.properties"/>

you can pass mule.env during deployment

Question 13

You can define the property placeholder or secure property placeholder in application as below

secure-property-placeholder:config name="Secure_Property_Placeholder" key="${secure.key}" location="file:///${config.path}/my-application-secure-${env}.properties" doc:name="Secure Property Placeholder
You will need to define the variable "env" , "config.path" either in wrapper.conf or passing the parameter when you start mule. e.g.

env = DEV, TEST, PROD etc config.path= /opt/mule/config/

Keep the name of your property file as my-application-secure-DEV.properties, my-application-secure-TEST.properties etc..

Question 14

Yes you can have deploy.properties but as many people suggested its good to have environment specific and business specific properties separately. As part of my experience we used three types like business, application and system and this properties are based on the environment.