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.