The Fabric3 Server runtime image is organized in the following way:
/bin |
|
|
|
| Startup modules |
|
/lib |
|
|
|
| Modules required to start the runtime host |
|
/boot |
|
|
|
| Modules required for the runtime bootstrap and primordial system services |
|
/host |
|
|
|
| Libraries shared between the runtime and application (e.g. web services annotations) |
|
/extensions |
|
|
|
| Extension modules that are able to be loaded by all runtime instances |
|
/runtimes |
|
|
|
| Specific runtime instance configuration is hosted by default under this directory |
|
| <runtime-name> |
|
|
| top level directory for a runtime configuration |
|
|
| /config |
|
| Contains systemConfig.xml for configuring the runtime and extensions |
|
|
| /deploy |
|
| File system deploy directory for the controller and single-VM runtimes |
|
|
| /repository |
|
|
|
|
|
|
| /runtime |
| Extensions only loaded for the runtime image |
|
|
|
| /user |
| User contributions (only populated on the controller and single-VM runtimes) |
|
|
| /data |
|
| Persistent data directory for a runtime instance (e.g. transaction log) |
|
|
| /tmp |
|
| Temporary data and artifact cache for a runtime instance |
|
If the default runtime startup command is used:
java -jar server.jar |
a single-VM instance will be created using the configuration specified in runtimes/vm. Alternative configurations can be used by specifying the runtime name as shown below. The runtime name will map to a configuration contained under the {{runtimes} directory:
java -jar server.jar controller -- launches a runtime using the configuration under runtimes/controller java -jar server.jar participant -- launches a runtime using the configuration under runtimes/participant java -jar server.jar foo -- launches a custom runtime using the configuration under runtimes/foo image |
Note it is possible to run multiple runtime instances from a single disk image. In this case, the image will contain multiple configurations under the runtimes directory. Each instance can then be started by specifying the runtime name, for example:
java -jar server.jar foo java - jar server.jar foo2 |
To start the runtime in clean mode, use the clean command:
java -jar server.jar clean |
Note starting the runtime in clean mode will delete information stored in the data directory, including transaction recovery logs.
For high-density clustered topologies such as cloud environments, Fabric3 provides the ability to clone runtimes. This allows new instances to be spawned from a configuration template using a single command without the need for manual setup. The following command clones a runtime image and launches the cloned instance:
java -jar server.jar clone:template runtime2 |
If more than one domain is run on the same physical network, it is necessary to create unique domain names. The domain name is configured using the domain attribute of the <runtime> element:
<config> <runtime domain="mydomain"/> </config> |
The domain name must be a valid URI host and not contain characters such as ":" or "/". The default domain name is domain.
The runtime mode is configured using the mode attribute of the <runtime> element:
<config> <runtime mode="controller"/> </config> |
Valid values are: vm; participant; and controller. For more information on the runtime mode setting, see The Domain.
By default, Fabric3 is configured to use pass-by-reference semantics when invoking remotable services collocated with their clients. This avoids the overhead of parameter copying. In some cases, this may not be desirable, for example, if a service directly modifies parameter data that should not be visible to clients. To avoid this, the runtime can be configured to follow SCA by-value semantics by setting the @enableByValue attribute to true on the SCA setting in serviceConfig.xml:
<sca enableByValue="true"/> |