Apache Felix iPOJO Feature Overview

This page is an attempt to put all of the features and benefits of iPOJO into a single high-level list so that it is easy to see why you will want to use iPOJO for your applications. This list is not exhaustive, but represents the set of features that are potentially most likely to be needed or are unique.

• POJO-based approach - Most components can simply be POJOs and need not have an iPOJO- or OSGi-specific API in them.
• Simple service provisioning - iPOJO manages all aspects of providing an OSGi service.
  • Service property management
    • Can be controlled by configuration properties.
    • Can be mapped to member fields and automatically updated by the component instance at run time by just changing the member field value.
  • Service life cycle participation - The component instance can participate in the service life cycle by declaring a boolean member field that indicates when the service is actually valid (normally a service is assumed to be valid if the component instance's dependencies are satisfied).
• Rich service dependency model - Automatically manages a full spectrum of service dependencies.
  • Optional/mandatory service dependencies.
  • Singular/aggregate service dependencies.
  • Member field/method injection - Also supported in combination.
    • Member method injection supports various method signatures
      • method() - Acts as a simple event-callback mechanism.
      • method(<service-interface> svc) - Receives the service object cast to the appropriate interface.
      • method(ServiceReference ref) - Receives the OSGi ServiceReference for the service object.
      • method(ServiceReference ref, <service-interface> svc) - Receives the OSGi ServiceReference and the service object cast to the appropriate interface.
  • Binding policies - Allow components to control how/when there dependencies are bound.
    • Static - Static dependencies cannot change without invalidating the component instance, so injected services typically do not change at run time and service departures typically result in the component instance being destroyed and potentially recreated. (coming soon)
    • Dynamic - Dynamic dependencies can change without invalidating the component instance, so injected services can change at run time, but are static with respect to service priority changes (i.e., they do not automatically switch if a higher priority service appears).
    • Dynamic priority - Dynamic priority dependencies can change without invalidating the component instance and do dynamically update based on service priority rankings at run time. (coming soon)
• Configuration property management - Integrated with OSGi Config Admin service.
  • Member field/member method injection - Also supported in combination.
  • Service property propagation - Configuration properties can be configured to update service properties if the component instance is providing a service.

• Sophisticated concurrency handling - Externalizes concurrency issues so that component code does not need to worry about services changing while they are in use (i.e., no locking protocol in component code).