Feature available in Fabric3 1.9
It is often necessary to provide application configuration that varies by runtime environment. For example, service endpoint URLs, JMS connection information, and JDBC data source URLs may differ for testing and production environments.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" xmlns:f3-tests="org.codehaus.fabric3.tests">
<deployable composite="f3-tests:ProductionComposite" environments="production"/>
<deployable composite="f3-tests:TestComposite" environments="development test"/>
</contribution>
|
In the above example, ProductionComposite is configured to deploy only when the runtime is booted in the production environment. TestComposite, in contrast, specifies a space-delimited list of environments. Specifically, it will be activated when the runtime is booted in the development or test environment. If no value is specified, the default "production" value will be used. This means that if an environment is not specified for a runtime in systemConfig.xml and a deployable composite entry does not contain and environments an @environments attribute, the composite will be activated as both values will default to production.
Creating Environment-Specific Configuration
Using named environments, an application can specify datasource, JNDI, and other resource configuration that is specific to an environment. It is also possible to activate a set of components for a specific environment. To do this, place the resource definitions in a composite or set of composites that are configured to activate in production, testing or some other environment. These composites can then be contained in a single contribution or in an external contribution.
...
Binding configuration such as endpoint addresses may often change from testing to production. Fabric3 provides a simple templating mechanism whereby this binding information may be substituted at deployment time. The following demonstrates how to use binding<binding.template template> to substitute web service configuration:
...
The <binding.template> element instructs the runtime to substitute the specified template when the contribution is installed in a runtime. The template is defined using the <template> element in a composite:
...
The template composite can be contained in the same contribution or placed in a different contribution. If it is in the same contribution, the named environments feature described above can be used to activate different template definitions depending on the environment. For example, production and testing template composites can be provided.
As previously mentioned, it is also possible to place composites containing template definitions in a different contribution. In this case, the contribution containing the template must be installed prior to any contributions containing references to it (note Note that the Fabric3 capabilities ordering feature can be used to have the runtime automatically order template and referring contributions).
...
In addition to including template definitions in a contribution, it is also possible to include specify them in the controller systemConfig.xml (. Note participant runtimes do not need to have template definitions as the information is only used by the controller). The following shows how to specify a template in systemConfig.xml:
...