AppBundles Overview

AppBundles can be used as a loaded top-level configuration or a nested component(s).

• Top-Level Configurations
  • These bundles are loaded either through the Aspire Admin Home Page, or specified in the config/settings.xml file as an “<autoStart>” parameter.
• Nested Configurations
  • AppBundles can be specified within other component managers or pipeline managers with a special <appBundle> tag.
  • When this happens, the AppBundle will be “nested” within the larger component manager.
  • This mechanism allows for AppBundles to become single pipeline stages or components within larger and more comprehensive configurations.

Use Cases

The following are a few use cases anticipated for AppBundles:

1. Connectors: Package connectors are complex configurations containing multiple components. These will be stored in AppBundles so they can be shared across multiple customer installations, unchanged.
2. Search Engine Publishers: Since the new Aspire Connectors will all produce a common output format, off-the-shelf search engine configurations can be stored as AppBundles and re-used as necessary. The goal is to create common configurations which depend on common (and well documented) AspireObject structures, and to share these standard configurations using App Bundles.
3. Text Analytics Components: Text Analytics is a complex process involving multiple batch runs with many configured components. It is hoped that re-usable text analytics components can be created with AppBundles.
4. Distributed Processing: AppBundles will significantly improve how multiple nodes in a distributed Aspire cluster can be updated. Since all applications are stored centrally in a Maven Repository, all cluster nodes can download and update themselves automatically, without having to copy files around and restart servers.

What is an AppBundle?

An AppBundle is a JAR file that is stored in Maven.

Referenced by Maven coordinates

AppBundles are referenced by Maven coordinates, as follows:

  {group-id}:{artifact-id}:{version}

For example:

• com.searchtechnologies.appbundle:aspire-filesystem-connector:0.5-SNAPSHOT; or
• aspire-filesystem-connector, defaulting to the above using the default group id and versions specified in the settings file.

Like standard Aspire Components, AppBundles will be downloaded automatically by Aspire from Maven repositories configured in the settings.xml file.

Contains an Aspire configuration file

AppBundles must contain an Aspire configuration file stored in "config/application.xml"

This is the only thing that is required to be stored in an AppBundle.

Note: Due to the way components are download from Maven, care should be taken when referencing components to download from the application.xml file. Aspire utilizes default groupId and version ids that could be overridden. You are advised to give careful consideration to specifying components Maven coordinates fully ({group-id}:{artifact-id}:{version}) to ensure that the component version you expect will be used, regardless of final system defaults.

May contain other files

AppBundles can also contain any other files stored in other directories.

Other files will typically include things like:

• Data files which are loaded on startup, including, possibly, Apache Derby databases.
  • Stored in "data"
• Web user interface files for any HTTPFeeder-based interfaces delivered with the App Bundle
  • Stored in "web"
• Any supporting libraries required, such as JDBC drivers
  • Stored in "lib"
• XSLT transforms for posting documents to servers, etc.
  • Stored in "config"

May not contain these files

The following files are typical for an Aspire Distribution, but must NOT be in an AppBundle:

• No bin files (in the "bin" directory)
• No resource files (in the "resources" directory)
  • These are reserved for true Aspire Components (i.e., standard component Bundles, not AppBundles)
• No log files

App Bundles and Properties

Components configured in an AppBundle may make use of properties by way of the ${propertyName} notation. In Aspire today, these properties are set in the settings.xml file. With AppBundles, it will be possible to set properties for a specific AppBundle, by specifying them when including the AppBundle:

 <component name=”MyName” appBundle=”aspire-filesystem-connector”>
   <property name=”propertyName”>propertyValue</property>
 </component>

In the case that the given property name is the same as a system property, the value configured for the AppBundle will take precedence, but for that AppBundle only. Any other component will use the value configured in the settings file. Any other AppBundle will use its own value (if configured) or the one from the settings file.

Properties can be specified in the settings.xml

For AppBundles that are loaded on startup and specified in the <autoStart> tag, the properties can be specified directly in the settings.xml file.

See here for more information.

AppBundles can be pipeline managers

Since all Pipeline Managers are also Component Managers, there’s no reason why an AppBundle cannot be a pipeline manager. The only logic in the code preventing AppBundles (and all top-level configuration files) from being pipeline managers is that "default" is currently hard coded as the aspire-application subType in these instances.

Pipeline managers will be automatically determined from the configuration file, based on whether the configuration file contains a nested <pipelines> tag. Note that the <pipelines> tag must be a direct child of the root tag of the AppBundle configuration file. More deeply nested <pipelines> tags will not count.

Implications

This means that an AppBundle can also be a pipeline stage.

Since all pipeline managers can be pipeline stages, therefore an AppBundle can also be a pipeline stage. In other words, a single pipeline stage can now be an entire pipeline manager composed of many nested components, which can then be shared and installed in higher-level pipelines as needed.

AppBundle component paths

Suppose an application.xml file contains the top level tag:

 <application name=”MyComponentManager”>

If loaded into Aspire via the UI, a component manager named /MyComponentManager will be created and all components configured in the file will appear under this path:

 /MyComponentManager/component1
 /MyComponentManager/component2
 /MyComponentManager/pipelineManger
 /MyComponentManager/pipelineManger/stage1
 .
 .
 .

If the same system file were loaded as a nested AppBundle using the following definition:

<application name="MyNewApp">
  <components>
    <component name="MyName" appBundle=”aspire-filesystem-connector”>
      <property name=”propertyName”>propertyValue</property>
    </component>
  </components>
</application>

Then the name attribute (MyComponentManager) from the AppBundles's application.xml is ignored. The AppBundle will be named as "MyName" as specified on the <component> tag which references the AppBundle:

/MyNewApp/MyName/component1
/MyNewApp/MyName/component2
/MyNewApp/MyName/pipelineManger
/MyNewApp/MyName/pipelineManger/stage1
.
.
.

AppBundles and AspireHome

When an AppBundle is downloaded and installed, it is impossible for Aspire to merge directories under "AspireHome". Thus, each AppBundle will be given its own "AspireHome" directory. This will be known as "AppBundleHome".

See also:

• Aspire Directory Structure - For a complete description of the entire Aspire directory structure.
• Property Substitution for a description of how properties are substituted, including ${appbundle.home} ${aspire.home}.