Properties - SwitchYard 1.1

SwitchYard supports two types of properties, Environment Properties and Implementation Properties. These two types of properties support distinct use cases within SwitchYard, yet they are compatible. For example, an implementation property can be injected into application logic with a value from an environment property.

Note

While SCA supports complex type of properties, SwitchYard only supports simple String name/value type of properties for now. Complex property support will be added in the future.

Environment Properties

Environment properties allow you to replace any attribute or element value in switchyard.xml with a property from the runtime environment. The syntax for a replaced token is "${varName}" where "varname" is your property name. The configuration layer in SwitchYard is configured with instances of PropertyResolver, which are used to resolve the value of a property based on its name. Property values are resolved from the following locations:

System properties passed by -D option of Java VM like "-Dproperty.name=property.value"
System environment variables, referenced with an "env." prefix, for example: env.PATH
Unit test properties
JBoss AS7 properties, including access into the SecurityVault
Domain properties in switchyard.xml
SCA property definitions in the composite or component

Property Overriding

SwitchYard property resolver scans the property in following order.

System properties and System environment variables
Unit test properties
JBoss AS7 properties
Domain properties
SCA composite properties
SCA component properties

For example, if you define the property inventory.interface in both of composite and component like this:

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:component name="InventoryService">
        <sca:service name="InventoryService">
            <sca:interface.java interface="${inventory.interface:org.switchyard.quickstarts.demos.orders.InventoryService}"/>
        </sca:service>
        <sca:property name="inventory.interface" value="org.switchyard.quickstarts.demos.orders.InventoryServiceEx"/>
    </sca:component>
    <sca:property name="inventory.interface" value="org.switchyard.quickstarts.demos.orders.InventoryServiceEx2"/>
</sca:composite>

In this case, the composite property "org.switchyard.quickstarts.demos.orders.InventoryServiceEx2" is used as the value of interface attribute. Note that the default value is specified as org.switchyard.quickstarts.demos.orders.InventoryService. You can specify the default property value with "${propertyName:defaultValue}" syntax where "propertyName" is the name of property. If you remove both of composite and component property from above, then the default value is used.

And if you pass a inventory.interface system property like this:

-Dinventory.interface=org.switchyard.quickstarts.demos.orders.InventoryServiceEx3

then the system property overrides all of other properties, so "org.switchyard.quickstarts.demos.orders.InventoryServiceEx3" is used as the value of interface attribute.

In order to set properties to test values, please refer to the "PropertyMixIn Injection" section of the Testing documentation.

Property Escaping

Sometimes, the desired value for a property needs to be in the same "dollar curly" syntax which triggers SwitchYard's property substitution. This can be problematic because in these cases, you want SwitchYard to leave the configured value alone. To accomplish this, use a "double dollar curly" syntax instead. Take the following example:

<foo value="${prop}"/>
<bar value="$${prop}"/>

Assuming the value "prop" is a resolvable property (say, equal to "test"), the value attribute of the foo element will be that value ("test"). However, the value attribute of the bar element will be "${prop}" (with one dollar sign).

Implementation Properties

Implementation properties allow you to inject one or more property values into a service implementation. This is based on the property support in the SCA assembly spec. Since the property is injected into service implementation logic, the injection mechanism itself is unique to each implementation type. The details for each implementation type follow:

Java : injected using @Property into a CDI bean
Camel : wired into Camel properties component and accessible in a Camel route using Camel's own varName property notation
BPEL : mapped into process variables via an <assign> with using resolveProperty() XPath custom function
BPMN 2 : inserted into process variables by data input associations
Drools : available in a global map

See each Service implementation section of the Developer Guide for more details.