Page History

...

A component is associated with an instance. This instance can either be specified directly, or you can specify its class. If you do the latter, the actual instance will be created lazily.

Changes in the state of the component will trigger the following life cycle methods:

• init,
• start,
• stop and
• destroy.

The dependency manager will look for methods with these names and one of the following signatures in this order:

• (Component),
• ().

If you don't specify anything, the methods with these names will be invoked on the instance. By using setCallbacks() you can however change this behavior: You can change the names of the methods to look for. Any methods that are set to {{ null }} will not be invoked at all. Another thing you can do is to specify a different instance to invoke these methods on. If you do that, you will usually want to use the first signature, which gives you a reference to the {{ Component }} whose life cycle method was invokedIf you declare a component not by specifying an instance, but a class, the instance will be lazily created. Also, when found, the following life cycle methods will be invoked on your component instance: init, start, stop and destroy.

Interfaces and properties

...

When implementing more complex components, you often find yourself using more than one instance. However, several of these instances might want to have dependencies injected. In such cases you need to tell the dependency manager which instances to consider. This has to be a fixed set of instances however.

Factories

Out of the box, there already is support for lazy instantiation, meaning that the dependency manager can create component instances for you when their required dependencies are resolved. However, sometimes creating a single instance using a default constructor is not enough. In those cases, you can tell the dependency manager to delegate the creation process to a factory.

...

A configuration dependency is always required, and allows you to depend on the availability of a valid configuration for your component. Optional configuration dependencies are not supported because in that case you can just as well register as a {{ ManagedService }} yourself.

Resource

A resource dependency allows you to depend on a resource. A resource is a URL and you can use a filter condition based on protocol, host, port, path and URL.

...

All dependencies share a common API which you can implement yourself if you need a special type of dependency.

TODO explain this, there is an example test that contains a simple demo

Monitoring and Shell

Service Interfaces for Monitoring

Whilst not entirely trivial, this allows you to create your own types of dependencies. This can be useful for various scenarios where you want to have components that depend on things that are not services, bundles or configuration.

An example implementation can be found in one of the many test cases for the dependency manager: {{ CustomDependencyTest }}. This implements a dependency that can be made available and unavailable by manipulating a {{ Toggle }} which can be made available or unavailable. You basically have to implement two interfaces: {{ Dependency }} and {{ DependencyActivation }}. The former contains the bulk of the methods that you will need to implement and depending on the actual features you want your dependency to support, you have to implement some or all of them. The JavaDoc for each method plus the example code should get you started. The latter contains a couple of life cycle methods to start and stop tracking your custom dependency.

Monitoring and Shell

The dependency manager has shell commands that allow you to inspect at runtime the state of the individual components and their dependencies. A separate bundle exists that enables these commands, and the shells it currently supports are: Apache Felix, Gogo and Eclipse Equinox Shell.

Filter Indices

These are still experimental.