The management agent we use is highly configurable and can be used in different ways. This document describes those options in detail.

There are basically three ways to use the management agent. You can use the ACE launcher, which combines an OSGi framework with an embedded management agent in a single, executable JAR file. This by far is the easiest way to get started. The second option is to use the "all in one" management agent bundle. You can drop this one in an existing OSGi framework easily and configure it with just a few options. The third and last option is to use the set of bundles that make up the management agent. If you want to extensively customize it, this is the best way to do so, but for normal use cases it's probably more complex than necessary.

Using the launcher

Usage: java -jar ace-launcher.jar [identification=<id>] [discovery=<ace-server>] [options...]

All known options are:

  • identification: sets the target ID to use
  • discovery: sets the ACE server to connect to
  • agents: configures multiple management agents: agent-id,identification,discovery[;agent-id,identification,discovery]*
  • fwOption: sets framework options for the OSGi framework to be created. This argument may be repeated
  • help: prints this help message

Example:
java -jar ace-launcher.jar identification=MyTarget discovery=http://provisioning.company.com:8080 fwOption=org.osgi.framework.system.packages.extra=sun.misc,com.sun.management

Using the management agent bundle

We have a pre-configured and pre-packaged management agent as a single bundle. It can be configured using system properties:

  • identification: sets the target ID to use
  • discovery: sets the ACE server to connect to
  • agents: configures multiple management agents: agent-id,identification,discovery[;agent-id,identification,discovery]*

Using the set of fine grained bundles

For development, the options above provide a lot of flexibility.

The bundles that are needed for the management agent are:

  • org.apache.ace.identification.ifconfig implements and publishes the Identification service, which is used to identify the gateway. This bundle uses ifconfig to get to the MAC address of the network card.
  • org.apache.ace.discovery.property implements the Discovery service, which uses a configured property to "discover" the URL of the provisioning server.
  • org.apache.ace.deployment contains the actual deployment engine to install and update deployments.
  • org.apache.ace.deployment.task contains the schedulable task that invokes the deployment engine.
  • org.apache.ace.scheduler a simple scheduler that schedules tasks.
  • org.apache.ace.configurator a bundle that picks up configurations from a "conf" folder and puts them in Configuration Admin. It uses plain property files that are named after the symbolic names of the bundles they configure (with .cfg extension). Factories are represented as directories (with .cfg files inside).
  • org.apache.ace.gateway.log log synchronization task, which synchronizes local logs with the provisioning server.
  • org.apache.ace.gateway.log.store local log store, stores all logs locally.
  • org.apache.ace.log log contains some logging interfaces.
  • org.apache.ace.log.listener listener for log events that need to be recorded to the audit log.
  • org.osgi.compendium OSGi compendium bundle, contains interfaces.
  • org.osgi.mobile OSGi mobile compendium bundle, contains interfaces.
  • javax.servlet servlet API, required by the OSGi compendium.
  • org.apache.felix.dependencymanager dependency manager implementation bundle.
  • org.apache.felix.configadmin configuration admin service implementation, needed to configure certain aspects of the management agent.
  • org.apache.felix.eventadmin event admin implementation, needed to listen to certain vital events during deployment.
  • org.apache.felix.deploymentadmin deployment admin implementation from Apache Felix.
  • log_all log service, any implementation will do here, this one is from Knopflerfish.
  • consolelogger dumps the log to the console, using any log service implementation.

So, what can you actually configure?

  • The management agent itself can be configured and uses Configuration Admin. The configurator bundle is merely a way to get data in Configuration Admin, but could be replaced if you, for example, want to hardcode this information in a different way.
  • The scheduler actually makes sure the tasks (which are services) are invoked regularly. You can replace it with your own scheduler that uses a completely different algorithm to invoke these tasks.
  • The identification service determines the way the management agent identifies itself to the server.
  • The discovery service determines the way the management agent actually "discovers" the server.
  • No labels