Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

From Camel 2.10: Spring's property placeholder can be bridged with Camel's. See below for more details.

...

The value of a Camel property can be obtained by specifying its key name within a property placeholder, using the following format: {{key}}.

For example:

...

...

where file.uri is the property key.

...

From Camel 2.14.1: you can specify a default value to use if a property with the key does not exists, e.g., file.url:/some/path where the default value is the text after the colon, e.g., /some/path.

...

...

From Camel 2.14.1: do not use a colon in the property key. The colon character is used as a token separator when providing a default value.

Using PropertyResolver

Camel provides a pluggable mechanism that allows third-parties to specify their own resolver to use for the lookup of properties.

...

The PropertiesResolver must be configured with the location(s) to use when resolving properties. One or more locations can be given. Specifying multiple locations can be done a couple of ways: using either a single comma separated string, or an array of strings.

...

...

From Camel 2.19.0: you can set which location can be discarded if missing by setting  optional=true, (false by default).

Example:

 

Code Blocklanguagejavapc.setLocations("com/mycompany/override.properties;optional=true,com/mycompany/defaults.properties");

 

Using System and Environment Variables in Locations

...

The location now supports using placeholders for JVM system properties and OS environments variables.

Example:

...

...

In the location above we defined a location using the file scheme using the JVM system property with key karaf.home.

To use an OS environment variable instead you would have to prefix with env:

...

...

Where APP_HOME is an OS environment variable.

You can have multiple placeholders in the same location, such as:

...

...

Using System or Environment Variables to Configure Property Prefixes and Suffixes

...

Assume the PropertiesComponent is configured with the following properties file:

...

...

The same properties file is then referenced from a route definition:

...

By using the configuration options propertyPrefix it's possible to change the target endpoint simply by changing the value of the system property stage either to dev (the message will be routed to mock:result1) or test (the message will be routed to mock:result2).

...

You have to create and register the PropertiesComponent under the name properties such as:

...

Configuring in Spring XML

Spring XML offers two variations to configure. You can define a spring bean as a PropertiesComponent which resembles the way done in Java DSL. Or you can use the <propertyPlaceholder> tag.

...

...

Using the <propertyPlaceholder> tag makes the configuration a bit more fresh such as:

...

Setting the properties location through the location tag works just fine but sometime you have a number of resources to take into account and starting from Camel 2.19.0 you can set the properties location with a dedicated propertiesLocation:

...

...

From Camel 2.10: Camel supports specifying a value for the cache option both inside the Spring as well as the Blueprint XML.

Using a Properties from the Registry

...

Then you could setup the Properties component as follows:

...

...

Where myProperties is the id to use for lookup in the OSGi registry. Notice we use the ref: prefix to tell Camel that it should lookup the properties for the Registry.

...

When using property placeholders in the endpoint URIs you can either use the properties: component or define the placeholders directly in the URI. We will show example of both cases, starting with the former.

...

...

You can also use placeholders as a part of the endpoint URI:

...

...

In the example above the to endpoint will be resolved to mock:result.

You can also have properties with refer to each other such as:

...

Notice how cool.concat refer to another property.

The properties: component also offers you to override and provide a location in the given URI using the locations option:

...

...

Examples

You can also use property placeholders directly in the endpoint URIs without having to use properties:.

...

And you can use them in multiple wherever you want them:

...

You can also your property placeholders when using ProducerTemplate for example:

...

Example with Simple language

The Simple language now also support using property placeholders, for example in the route below:

...

...

You can also specify the location in the Simple language for example:

...

...

Additional Property Placeholder Support in Spring XML

The property placeholders is also supported in many of the Camel Spring XML tags such as <package>, <packageScan>, <contextScan>, <jmxAgent>, <endpoint>, <routeBuilder>, <proxy> and the others.

Example:

...

Example:

...

...

Overriding a Property Setting Using a JVM System Property

Available as of Camel 2.5
It is possible to override a property value at runtime using a JVM System property without the need to restart the application to pick up the change. This may also be accomplished from the command line by creating a JVM System property of the same name as the property it replaces with a new value.

Example:

...

...

Using Property Placeholders for Any Kind of Attribute in the XML DSL

Available as of Camel 2.7

...

...

If you use OSGi Blueprint then this only works from 2.11.1 or 2.10.5 on.

Previously it was only the xs:string type attributes in the XML DSL that support placeholders. For example often a timeout attribute would be a xs:int type and thus you cannot set a string value as the placeholder key. This is now possible from Camel 2.7 on using a special placeholder namespace.

In the example below we use the prop prefix for the namespace http://camel.apache.org/schema/placeholder by which we can use the prop prefix in the attributes in the XML DSLs. Notice how we use that in the Multicast to indicate that the option stopOnException should be the value of the placeholder with the key stop.

...

...

In our properties file we have the value defined as

...

...

Using Property Placeholder in the Java DSL

...

Likewise we have added support for defining placeholders in the Java DSL using the new placeholder DSL as shown in the following equivalent example:

...

...

Using Blueprint Property Placeholder with Camel Routes

...

Camel supports Blueprint which also offers a property placeholder service. Camel supports convention over configuration, so all you have to do is to define the OSGi Blueprint property placeholder in the XML file as shown below:

...

...

By default Camel detects and uses OSGi blueprint property placeholder service. You can disable this by setting the attribute useBlueprintPropertyResolver to false on the <camelContext> definition.

...

...

Notice how we can use the Camel syntax for placeholders {{ }} in the Camel route, which will lookup the value from OSGi blueprint.
The blueprint syntax for placeholders is ${}. So outside the <camelContext> you must use the ${} syntax. Where as inside <camelContext> you must use {{ }} syntax. OSGi blueprint allows you to configure the syntax, so you can actually align those if you want.

You can also explicit refer to a specific OSGi blueprint property placeholder by its id. For that you need to use the Camel's <propertyPlaceholder> as shown in the example below:

...

Notice how we use the blueprint scheme to refer to the OSGi blueprint placeholder by its id. This allows you to mix and match, for example you can also have additional schemes in the location. For example to load a file from the classpath you can do:

...

Each location is separated by comma.

...

When using Blueprint property placeholder in the Blueprint XML file, you can declare the properties directly in the XML file as shown below: Wiki Markup{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-test-blueprint/src/test/resources/org/apache/camel/test/blueprint/configadmin-outside.xml}Notice that we have a <bean> which refers to one of the properties. And in the Camel route we refer to the other using the {{ }} notation.

Now if you want to override these Blueprint properties from an unit test, you can do this as shown below: Wiki Markup{snippet:id=e1|lang=java|url=camel/trunk/components/camel-test-blueprint/src/test/java/org/apache/camel/test/blueprint/ConfigAdminOverridePropertiesOutsideCamelContextTest.java}To do this we override and implement the useOverridePropertiesWithConfigAdmin method. We can then put the properties we want to override on the given props parameter. And the return value must be the persistence-id of the <cm:property-placeholder> tag, which you define in the blueprint XML file.

...

For example in the blueprint XML file we have the persistence-id="stuff", which mean it will load the configuration file as etc/stuff.cfg. Wiki Markup{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-test-blueprint/src/test/resources/org/apache/camel/test/blueprint/configadmin-loadfile.xml}Now if you want to unit test this blueprint XML file, then you can override the loadConfigAdminConfigurationFile and tell Camel which file to load as shown below: Wiki Markup{snippet:id=e1|lang=java|url=camel/trunk/components/camel-test-blueprint/src/test/java/org/apache/camel/test/blueprint/ConfigAdminLoadConfigurationFileTest.java}Notice that this method requires to return a String[] with 2 values. The 1st value is the path for the configuration file to load. The second value is the persistence-id of the <cm:property-placeholder> tag.

The stuff.cfg file is just a plain properties file with the property placeholders such as:

...

Using a .cfg file and Overriding Properties for Blueprint Property Placeholders

You can do both as well. Here is a complete example. First we have the Blueprint XML file: Wiki Markup{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-test-blueprint/src/test/resources/org/apache/camel/test/blueprint/configadmin-loadfileoverride.xml}And in the unit test class we do as follows: Wiki Markup{snippet:id=e1|lang=java|url=camel/trunk/components/camel-test-blueprint/src/test/java/org/apache/camel/test/blueprint/ConfigAdminLoadConfigurationFileAndOverrideTest.java}And the etc/stuff.cfg configuration file contains:

...

...

Bridging Spring and Camel Property Placeholders

...

To bridge Spring and Camel you must define a single bean as shown below: Wiki Markup{snippet:id=e1|lang=xml|title=Bridging Spring and Camel property placeholders|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/component/properties/CamelSpringPropertyPlaceholderConfigurerTest.xml}You must not use the spring <context:property-placeholder> namespace at the same time; this is not possible.

After declaring this bean, you can define property placeholders using both the Spring style, and the Camel style within the <camelContext> tag as shown below: Wiki Markup{snippet:id=e2|lang=xml|title=Using bridge property placeholders|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/component/properties/CamelSpringPropertyPlaceholderConfigurerTest.xml}Notice how the hello bean is using pure Spring property placeholders using the ${} notation. And in the Camel routes we use the Camel placeholder notation with {{ }}.

...

Take notice when using Spring bridging placeholder then the spring ${} syntax clashes with the Simple in Camel, and therefore take care.

Example:

...

...

clashes with Spring property placeholders, and you should use $simple{} to indicate using the Simple language in Camel.

...

...

An alternative is to configure the PropertyPlaceholderConfigurer with ignoreUnresolvablePlaceholders option to true.

...

So for example in your unit test classes, you can override the useOverridePropertiesWithPropertiesComponent method and return a java.util.Properties that contains the properties which should be preferred to be used. Wiki Markup{snippet:id=e1|lang=java|title=Providing properties from within unit test source|url=camel/trunk/components/camel-test-blueprint/src/test/java/org/apache/camel/test/blueprint/ConfigAdminOverridePropertiesTest.java}This can be done from any of the Camel Test kits, such as camel-test, camel-test-spring and camel-test-blueprint.

...

Camel allows to inject property placeholders in POJOs using the @PropertyInject annotation which can be set on fields and setter methods. For example you can use that with RouteBuilder classes, such as shown below:

...

Notice we have annotated the greeting field with @PropertyInject and define it to use the key hello. Camel will then lookup the property with this key and inject its value, converted to a String type.

You can also use multiple placeholders and text in the key, for example we can do:

...

...

This will lookup the placeholder with they key name.

You can also add a default value if the key does not exists, such as:

...

...

Using Out of the Box Functions

...

As you can see these functions is intended to make it easy to lookup values from the environment. As they are provided out of the box, they can easily be used as shown below:

...

You can use default values as well, so if the property does not exists, you can define a default value as shown below, where the default value is a log:foo and log:bar value.

...

...

The service function is for looking up a service which is defined using OS environment variables using the service naming idiom, to refer to a service location using hostname : port

...

in other words the service uses _SERVICE_HOST and _SERVICE_PORT as prefix. So if the service is named FOO, then the OS environment variables should be set as

...

For example if the FOO service a remote HTTP service, then we can refer to the service in the Camel endpoint URI, and use the HTTP component to make the HTTP call:

...

And we can use default values if the service has not been defined, for example to call a service on localhost, maybe for unit testing etc:

...

Using Custom Functions

Available as of Camel 2.14.1

The Properties component allow to plugin 3rd party functions which can be used during parsing of the property placeholders. These functions are then able to do custom logic to resolve the placeholders, such as looking up in databases, do custom computations, or whatnot. The name of the function becomes the prefix used in the placeholder. This is best illustrated in the example code below

...

Here we have a Camel XML route where we have defined the <propertyPlaceholder> to use a custom function, which we refer to be the bean id - e.g., the beerFunction. As the beer function uses beer as its name, then the placeholder syntax can trigger the beer function by starting with beer:value.

The implementation of the function is only two methods as shown below:

...

...

The function must implement the org.apache.camel.component.properties.PropertiesFunction interface. The method getName is  the name of the function, e.g., beer. And the apply method is where we implement the custom logic to do. As the sample code is from an unit test, it just returns a value to refer to a mock endpoint.

To register a custom function from Java code is as shown below:

...

...

See Also