Contents
This page describes the order in which application and fragment configuration is loaded. As part of node installation, default application and node configuration information is installed. When an application is initialized, there is a well-defined order in which configuration is processed:
-
Default configuration built in to the product.
-
Application definition configuration in the application archive.
-
Node deploy configuration in the application archive.
-
Node deploy configuration specified on the epadmin install node command line.
-
Configuration from fragments contained in the application archive, loaded in reverse classpath order.
-
Configuration from the application archive.
-
Configuration from the global configuration object in the node deploy configuration.
-
Configuration from the nodes object in the node deploy configuration.
-
Configuration from the engines object in the node deploy configuration file.
Configuration specified in the node deploy global or per-node configuration sections is processed in the order in which it is specified in the file — the first configuration is processed first, the second next, and so on.
This implies that configuration loaded after other configuration can override previously loaded and activated configuration (see this page for details on configuration replacement). A failure to load or activate a configuration file causes the node startup to fail.
Additional load order considerations:
-
Load order can be affected by configuration-merge strategies for supported engine properties. See HOCON Configuration Merging for more information.
-
Load order can also be affected if a load order dependency rule is configured in a Studio Run Configuration dialog for EventFlow or LiveView fragments. This feature lets you specify one configuration file (say, B) as a prerequisite for another, A. In this case, when Studio runs the fragment, it loads B before A independent of other load order considerations. See Main Tab, Configuration Settings for more information.
When an application is installed, fragment configuration is loaded using the classpath of the top-level fragment (Fragment-A and Fragment-B as shown below) engines. For each engine, fragment configuration is loaded in reverse classpath order. If there are duplicate dependencies in the classpath, the configuration for the duplicate dependency is loaded only once when the dependency is first processed during startup. If an application archive itself has multiple classpath elements containing configuration, this configuration is also loaded in reverse classpath order. Finally, if there are multiple configuration files in a single classpath element, they are loaded in ASCII sort order.
Configuration load ordering between engines is undefined.
|
Using the application dependencies shown above, configuration would be loaded in this order (assuming Fragment-A engine is loaded before Fragment-B engine — this is undefined behavior).
-
Fragment-A engine
-
c.conf
-
a.conf
-
-
Fragment-B engine
-
d.conf
-
e.conf
-
(c.conf skipped, already loaded as part of Fragment-A engine processing)
-
b.conf
-
-
Application
-
x.conf
-
A subset of the epadmin install node parameters can also be set in configuration as shown below. If a value is set both in configuration and on the command line, the command-line value takes precedence.
TIBCO recommends that you use configuration files instead of command-line parameters to ensure consistency of application deployment on multiple machines.
| Node Install Parameter | Configuration Property Equivalent |
|---|---|
| adminhost | Administration.address |
| adminport | Administration.transportPort |
| application | None |
| buildtype | Execution.buildType |
| deploydirectories | None |
| discoveryhosts | Communication.discoveryRequestAddresses |
| discoveryport | Communication.discoveryPort |
| javabinarypath | None |
| javaenvironment | None |
| javahome | None |
| javalibrarypath | None |
| memoryallocators | SharedMemory.memoryAllocators |
| memorysize | SharedMemory.memorySizeBytes |
| memorytype | SharedMemory.memoryType |
| nodedeploy | None |
| nodedirectory | None |
| nodename | None |
| producthome | None |
| substitutions | None |
| substitutionfile | None |
| webenabled | Administration.webEnable |
| webport | Administration.webPort |
You can override both the application and node configuration information by specifying a node deploy configuration file when installing a node.