Other Version 0.5 Changes

From wiki.searchtechnologies.com
Jump to: navigation, search

For Information on Aspire 3.1 Click Here

Aspire / Version 0.5 Release Notes / Other Version 0.5 Changes


The thing which is loaded at the main Aspire configuration page is now, officially, called an "application". A single instance of Aspire can load any number of applications.

"Applications" can now be loaded into Aspire either from a configuration file on the file system or an "Application Bundle" downloaded from Maven using Maven Coordinates.

system.xml is now application.xml

Each application can be represented either by a configuration file. This used to be called "system.xml" (or "system-example.xml") and from now on will be called "application.xml".

App Bundles will now have "application.xml" embedded into them

App Bundles previously had a hardcoded dependency on "system.xml". This has been changed to "application.xml".

settings.xml <autoStart> now contains <application> instead of <componentManager>

The embedded auto-start tag is now <application> rather than <componentManager> in keeping with the new renaming to installed applications.

For example, in Version 0.4 you wrote:

   <componentManager config="config/system.xml"/>  <!-- This is old, will no longer work in 0.5! -->

Now, in version 0.5, this becomes:

   <application config="config/application.xml"/>

The root XML tag for all application.xml files is now <application>

The old system.xml file required <config> as the top-level tag. This has been changed to <application> for the new application.xml file.

Note that <config> is still available, but officially deprecated. It may no longer be available in future versions.

<config> inside <component> is now deprecated

The <config> tag, previously required inside every component is now deprecated. Now components can be configured without any embedded <config> tag. This cleans up the application.xml file, reduces nesting, and reduces the possibility for error.

For example the following configuration:

  <component name="MyComponent" factoryName="aspire-tools" subType="feedOne">
    <config>                                               <!-- <config> TAG IS OFFICIALLY DEPRECATED -->

Can now be more simply written as:

 <component name="MyComponent" factoryName="aspire-tools" subType="feedOne">

Isn't that so much nicer?

The Directory Structure of an Aspire Distribution is Formalized

You can get all of the details of the Aspire directory structure at Aspire Directory Structure.

The purpose of these changes to provide "safe" places whereby Aspire applications can co-exist without stepping on each other's data. This will become important as customers install more and more applications onto the same instance of Aspire, possibly including applications from third parties.

Major changes include:

  • felix-cache and the new appbundle-cache are now put together in a top-level "cache" directory
  • A new "xsl" directory has been created inside "config" for holding custom XSL transforms
  • The structure of the data directory has been formalized:
    • data/shared - Where applications can share data
    • data/aspire - Data for the Aspire framework (mostly unused)
    • data/${app.name} - Data for the named application
  • The lib directory is now part of all standard distributions
  • The web directory now has sub directories
    • components - for web files for a particular component (rarely used)
    • httpfeeder - for web files associated with an httpfeeder servlet

Standard Config File Substitution Properties

There are now a number of standard properties which you can use inside your application.xml files.

For example, you can use ${app.name} for the top-level name of the application under which your configuration file is installed. Or ${app.data.dir} for the location of your application's data directory (see above, same as ${aspire.home}/data/${app.name}).

The complete list of standard properties can be found here: Standard Aspire Property Names.


More objects can be written as JSON. Including Jobs, metadata (i.e. AspireObject's), JobRoute's, etc.

JSON is now the default format for serializing jobs and metadata "across the wire", for exmaple between Aspire servers, or between the Aspire server and the end-user interface.

The exception to this rule is when an XSLT transform is required. In this case, XML is preferred, for example to search engines, or for the Aspire debug console (which is entirely XSLT based).