You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even if they have been less than 10 answers to the usage survey, the most requested feature is the support for Service Factories.
A Service Factory is a special kind of service that is called by the framework each time it is requested by a bundle: this allows to have one instance (or even implementation) of a service per bundle.
The methods called by the framework are get_service(bundle, service_registration) and unget_service(bundle, service_registration, service_object).
The concept of service factory is defined in the OSGi Core Specification, section 5.9, page 140 (for version 6.0).
The OSGI specification also defines the concept of Prototype Service Factory (section 5.10, page 140) which allows to have multiple service objects, even for the same bundle.
It uses the same un/get_service() methods as the service factory.
This concept also adds a ServiceObjects interface, retrieved with the BundleContext.get_service_objects(service_reference)method (see section 10.1.7.14, page 205).
Both concepts requires the addiction of the concept of service scope (section 5.3, page 134) and to review the way get_service() works, to follow the rules of section 5.4, as Pelix supports only a part of it.
As a result, this feature will come after the following steps:
Add support for the service scope property
Ensure the BundleContext.get_service() method works as defined by section 5.4.1 (getting a single service)
Add the ServiceObjects API
Add support for ServiceFactory
Add support for PrototypeServiceFactory
Update documentation
The text was updated successfully, but these errors were encountered:
ServiceFactory feature has been merged in the master branch.
The PrototypeServiceFactory is still to be developped, but might be added in 0.6.6 instead of 0.6.5.
PrototypeServiceFactory have been implemented successfully.
Tests have been added to check their behaviour and to validate that the ServiceObjects API works as described in the OSGi specifications.
A new feature has been added in order to have a sane behaviour: service auto-release.
When a consumer bundle stops, the framework now ensures that all the services it uses are released.
This doesn't mean you can avoid explicit releases, this is mainly a feature to keep a clean state even when a bundle activator fails when the bundle is stopping.
Even if they have been less than 10 answers to the usage survey, the most requested feature is the support for Service Factories.
A Service Factory is a special kind of service that is called by the framework each time it is requested by a bundle: this allows to have one instance (or even implementation) of a service per bundle.
The methods called by the framework are
get_service(bundle, service_registration)
andunget_service(bundle, service_registration, service_object)
.The concept of service factory is defined in the OSGi Core Specification, section 5.9, page 140 (for version 6.0).
The OSGI specification also defines the concept of Prototype Service Factory (section 5.10, page 140) which allows to have multiple service objects, even for the same bundle.
It uses the same
un/get_service()
methods as the service factory.This concept also adds a
ServiceObjects
interface, retrieved with theBundleContext.get_service_objects(service_reference)
method (see section 10.1.7.14, page 205).Both concepts requires the addiction of the concept of service scope (section 5.3, page 134) and to review the way
get_service()
works, to follow the rules of section 5.4, as Pelix supports only a part of it.As a result, this feature will come after the following steps:
BundleContext.get_service()
method works as defined by section 5.4.1 (getting a single service)ServiceObjects
APIThe text was updated successfully, but these errors were encountered: