Aspire Startup Procedure

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

For Information on Aspire 3.1 Click Here

This is a description of the boot-strapping procedure that Aspire uses when it first starts up.

  1. Admin user executes "bin/startup.bat".
  2. The startup script locates Aspire Home, using the following procedure:
    • Looks to see if ASPIRE_HOME exists, if so, then uses that directory.
    • Uses the current working directory if it is an Aspire distribution.
    • Uses the parent of the current working directory if it is an Aspire distribution.
    • Otherwise, returns an error.
  3. Changes the current working directory to Aspire Home.
  4. The startup script run the Java JVM ("java") with "bin/felix.jar", passing in properties for the Aspire working directory (com.searchtechnologies.aspire.home) and the Apache Felix properties file (felix.config.properties).
    • The felix properties file is assumed to be "config/felix.properties" in the Aspire home directory.
  5. Felix starts up and does the following:
    • Opens the felix.properties file sets properties.
    • Gets the list of auto-start bundles from the "felix.auto.start.1" property, loads all of the specified bundles.
      1. The auto-start bundles first start all of the system bundles (such as the log server, the HTTP server, the web console, etc.).
      2. At the end, the auto-start bundles start up the Aspire Application bundle.
  6. The Aspire Application Bundle executes.
    • AspireActivator.start() class is automatically called by OSGi.
    • The settings.xml file is located and loaded into memory.
      1. If com.searchtechnologies.aspire.settings exists and specifies a valid file, then it is used for the settings.xml file.
      2. Otherwise, the settings file will be assumed to be "config/settings.xml" inside the Aspire Home directory.
    • The Aspire Application registers a "/aspire" servlet with the OSGi HTTP service. It also registers as a listener on the service so it can be re-registered if the OSGi HTTP service should ever be stopped and restarted later.
    • The <autoStart> configuration files from settings.xml are located.
    • A new component manager instance is created for each configuration file specified in the <autoStart> tag of the settings.xml file.
    • The component manager will automatically load its configuration file and do the following:
      1. Load all of the components specified in the configuration file.
        • For each component, the component manager will call the AspireApplication to load the component factory.
          • The application will check to see if the Bundle Jar file for the component factory is already loaded, if so it does nothing.
          • If the factory is not yet loaded, each repository specified in the settings.xml file will be checked in turn to see if the bundle jar file can be located. If located, the bundle will be downloaded to the local file system and then loaded into Aspire.
          • If no repositories are specified in the settings file, a single distribution repository to "bundles/aspire" will be created, making all Jar files in this directory available.
          • Each bundle Activator for the Jar will be started by OSGi which, in turn, will create and register a component factory in OSGi for each bundle.
      2. Create a new component instance for every component specified in the configuration file.
        • The Component Manager will locate the appropriate factory for the component (based on the factory name, include group ID (defaults to com.searchtechnologies if not specified) and version, if specified) and will ask the factory to create the component with a name and configuration XML from the configuration file.
  7. If any of the components created by the above are feeders, and if the <autoStart> parameter of the feeder is "true", then the feeder will automatically start polling its data source and feeding documents.

And now the Aspire Application is fully started.