Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Reference Guide

Services

Life cycle

The dependency manager, as part of a bundle, shares the generic bundle life cycle explained in the OSGi specification. The life cycle of the dependency manager itself, and the services it manages, can be located inside the active state of the hosting bundle.

Each service you define gets its own life cycle, which is explained in the state diagram below.

TODO: add diagram

...

Interfaces and properties

Services in the context of the dependency manager can be published as OSGi services under one or more interface names, plus optionally a set of properties. This is no different than a normal OSGi service. It's important to mention that you don't have to register a service. If you don't, you basically created a component that can do work and have dependencies and a managed life cycle.

Composition

When implementing more complex services, 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.

Factories

Out of the box, there already is support for lazy instantiation, meaning that the dependency manager can create 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.

Aspects

Aspects, as part of aspect oriented programming, can be used in a dynamic environment such as OSGi to "extend" existing services and add certain "capabilities" to them. Examples of these are adding a specific caching mechanism to a storage service or implementing logging. Aspects in OSGi can be applied to services and can be added and removed at runtime.

Adapters

Adapters, like aspects, are used to "extend" existing services, and can publish different services based on the existing one. An example would be implementing a management interface.

Resource Adapters

Resource adapters work just like adapters, but instead of working with services, they work with resources. Resources are an abstraction introduced to provide a generic way of dealing with "blobs" and can be resources inside a bundle, filesystem or some kind of data store.

Dependencies

...

Injection

Callbacks

Types of Dependencies

...