Runtime properties

During the execution of an Integration you can provide a single property or a property file that will be made available at runtime.

Single property

Imagine you have a generic Route and you set a placeholder for certain information (ie, my.message variable):

property-route.groovy
from('timer:property')
    .log('property content is: {{my.message}}')

The simplest way to replace that variable with a real value is to use the --property flag (also shortcut by -p):

kamel run -p my.message=test-property property-route.groovy

At runtime, that variable will be substituted by the value you’ve provided. You can provide more than one single property at once by just adding the flag repeatedly (ie, --property prop1=val1 --property prop2=val2 …​)

You can also use runtime properties in Camel endpoints, for example to make the timer period configurable you can do as follows:

property-route.groovy
from('timer:property?period={{triggerPeriod}}')
    .log('property content is: {{my.message}}')

The simplest way to replace that variable with a real value is to use the --property flag (also shortcut by -p):

kamel run -p my.message=test-property -p triggerPeriod=3000 property-route.groovy

Property File

Another way to provide more property configuration at once is to use a property file.

my.properties
my.key.1=hello
my.key.2=world
property-route.groovy
from('timer:property-file')
    .routeId('property-file')
    .log('property file content is: {{my.key.1}} {{my.key.2}}')

You’ll need to provide a property file flag when launching the application:

kamel run --property file:my.properties property-route.groovy

The property file is parsed and its properties configured on the Integration. As soon as the application starts, you will see the log with the expected configuration.

Property from ConfigMap/Secret

In case some runtime properties are stored into a Configmap or a Secret, you can use the --property flag with a value of type respectively configmap:name-of-configmap or secret:name-of-secret to refer to the specific resource to use as runtime properties.

As an example, let’s create a Configmap named my-cm-rp containing the runtime properties to load. You can alternatively use any Configmap you’ve already stored in your cluster:

kubectl create configmap my-cm-rp --from-literal=name="Will Smith" --from-literal=period="2000"

In our Integration we can simply refer to the properties defined in the ConfigMap as we’d do with any other property:

property-configmap-route.groovy
from('timer:property?period={{period}}')
    .log('Hello {{name}}!')

Then we launch the run command with the --property flag whose value matches with the appropriate syntax to refer to my-cm-rp:

kamel run --property configmap:my-cm-rp property-configmap-route.groovy

The key-value pairs of the ConfigMap are loaded and used as runtime properties of the Integration. As soon as the application starts, you will see the log with the expected message.

Property from ConfigMap/Secret as file

When you have a lot of key-value pairs to store into a given ConfigMap/Secret, you may consider storing some runtime properties as a file into a specific key-value pair for the sake of simplicity.

The only constraint is to use .properties as a suffix of the key to indicate that the value is actually a property file, not a simple value.

As an example, let’s use the same Integration as the previous section but with a ConfigMap that contains all the properties into the same key-value pair.

For this we need a properties file as next:

some.properties
name=John Smith
period=2000

That we will load into a specific ConfigMap using the following command:

kubectl create configmap my-cm-rps --from-file=some.properties

Then we launch the run command with the --property flag whose value matches with the appropriate syntax to refer to my-cm-rps:

kamel run --property configmap:my-cm-rps property-configmap-route.groovy

The value of the key-value of the ConfigMap is loaded as a property file and used as runtime properties of the Integration. As soon as the application starts, you will see the log with the expected message.

Property collision priority

If you have a property repeated more than once, the general rule is that the last one declared in your kamel run statement will be taken in consideration. If the same property is found both in a single option declaration and inside a file/configmap/secret, then, the single option will have higher priority and will be used.

Build time properties

If you’re looking for build-time properties configuration you can look at the build-time properties section.

Back to top