Page History

...

• POJO-based approach - Most components can simply be POJOs and need not have an iPOJO- or OSGi-specific API in them.
• 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
    • 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.
  **

• 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).