Hot Deployment

FUSE ESB Kernel deployer

FUSE ESB Kernel has a file-based deployer that can also deploy non-OSGi artifacts by implementing deployment details registered in the OSGi registry. It can register URL handlers and other handlers provided by FUSE ESB Kernel like the OBR and Maven handlers. You can use the OBR handler to access existing OBR registries.

Figure 5.1 shows the architecture of the FUSE ESB Kernel deployer:

Figure 5.1. FUSE ESB Deployer Architecture

FUSE ESB Kernel supports hot deployment of OSGi bundles, exploded bundles, and custom deployers. The deployer provides additional deployment capabilities using different URL handlers and has an extensible architecture to support different kinds of deployable artifacts.

The deployer subsystem hot deploys everything under the \deploy directory in your install directory. FUSE ESB Kernel monitors JAR files in the \deploy directory. Each time a JAR file is copied to this directory, it is installed in the runtime. You can then update or delete the JARs and changes are handled automatically.

Deployment activities

The OSGi framework supports continuous deployment activities, including installation, removal, update, starting (activation) and stopping (de-activation) of a physical bundle. Once a bundle is installed in the platform, it can be activated if deployment dependencies associated with the bundle are fulfilled.

Deployment activities have a well defined series of states corresponding to a physical bundle's lifecycle. Activation (or de-activation) of a physical bundle causes the creation (or destruction) of a unique logical bundle, instantiated from a class inside the bundle called a bundle activator:

When the instance is created, the execution environment calls an activation method that signals the logical bundle that it is active.
When the logical bundle is active, it can publish or discover services and bind with other bundles by accessing the framework's services registry. The bundle can receive notifications of changes that occur in the framework by subscribing as an event listener.
When the physical bundle is de-activated, the execution environment calls a de-activation method.

Feature descriptors

To hot deploy features from the deploy directory, drop a feature descriptor in that directory. A bundle is created and its installation automatically triggers the installation of all features contained in the descriptor. Removing the file from the deploy directory uninstalls the features. To install a single feature, write a feature descriptor like the following:

<features>
  <repository>
      mvn:org.apache.servicemix.nmr/apache-servicemix-nmr/1.0.0/xml/features
  </repository>
  <feature name="nmr-only">
     <feature>nmr</feature>
  </feature>
</features>

For more information, see Provisioning OSGi Features.

Spring support

You can deploy an OSGi bundle using the Spring dynamic modules (Spring DM) framework. A Spring XML configuration file support is provided and a Spring deployer is included by default. The deployer can deploy plain Spring and Spring-DM configuration files. The deployer supports file-based OSGi configuration leveraged by Spring. You can change the configuration at runtime by modifying the file, for example, to change the logging configuration. The deployer dynamically transforms any Spring configuration file dropped into the \deploy directory into a valid OSGi bundle.

The generated OSGi manifest contains the following headers:

               Manifest-Version: 2
               Bundle-SymbolicName: [name of the file]
               Bundle-Version: [version of the file]
               Spring-Context: *;publish-context:=false;create-asynchronously:=true
               Import-Package: [required packages]
               DynamicImport-Package: *

The name and version of the file are extracted using a heuristic that matches common patterns. For example, my-config-1.0.1.xml becomes name = my-config and version = 1.0.1. The default imported packages are extracted from the Spring file definition and include all classes referenced directly.

To customize the generated manifest, include an XML element in your Spring configuration:

<spring:beans ...>
    <manifest>
        Require-Bundle= my-bundle
    </manifest>

Overview of deployment

The high level steps in deployment include:

Use the features install command to install components in the container. (See Using the features Subshell Commands.)
Build the OSGi bundle using the Maven mvn clean install command. (See Using Maven OSGi Tooling.)
Copy the created JAR to the \deploy directory of FUSE ESB. (See FUSE ESB Kernel deployer.)

Deployment examples

The "Deploying to an OSGi Container" chapter in FUSE Services Framework: Configuring and Deploying Endpoints describes how to package the WSDL-first FUSE Services Framework sample and deploy it in an OSGi container.

See Understanding the Example in Getting Started with FUSE ESB for information on the Spring configuration used to configure the endpoint for the cxf-osgi example and the Maven POM used to build the bundle.