Offer more functional callback methods for services that have aspects on them.
------------------------------------------------------------------------------
Key: FELIX-3201
URL: https://issues.apache.org/jira/browse/FELIX-3201
Project: Felix
Issue Type: Improvement
Components: Dependency Manager
Environment: n/a
Reporter: Xander Uiterlinden
When programmatically adding service dependencies using the Apache felix
dependency manager there are two ways to have the component brought its
dependencies when they come available. These are the following:
- have the service injected in the component; this is usually sufficient for
cases where there's only one service expected to satisfy the dependency
(1-to-1) .
- explicitly specify callback methods; callbacks can be used when there might
be more than one service satisfying the dependency (1-to-n). When a dependency
is marked optional, the callback method also helps to determine when the
dependency actually became satisfied.
When using callback methods with the dependency manager you can specify the
following callbacks:
- added; gets called when the service required has become available.
- changed; gets called when the service properties of a added required service
have changed.
- removed; gets called when the service required has become unavailable.
At first these callbacks seem pretty simple. Just add the service to the
component's internal administration on the added callback and remove it from
the administration whenever the removed callback is called. But, the dependency
manager also supports the concept of aspect services which make using the
callback method in a correct way a bit more difficult.
Aspect services are services that are put on top of another service while still
implementing the original service's interface. They allow you to implement
cross-cutting functional requirements.
In the OSGi service registry aspect services are individual services just like
'regular' singleton services. When using callback methods for dependencies a
component is informed of the add/remove of an aspect service, just like it is
when a 'regular' service is added/removed. When using injection for
dependencies the aspect is transparently injected. The callbacks also handling
aspect services the same way as 'regular' services makes it difficult for a
component developer to correctly implement these callbacks.
For example take the following scenario:
Component A expresses a service dependency to Service B.
Without any aspects in the container the following callbacks would be added on
Component A.
added(Service B)
But whenever there's an aspect running on top of Service B, the order of
callbacks would be as follows:
added(Service B)
added(Service B aspect)
removed(Service B)
When backed by a typical HashMap administration this would result in:
put(B.id, B)
put(B.id, B)
remove(B.id)
This sequence would result in an empty Map, which is not a desirable situation.
In order to ease the dependency handling an additional callback method is
needed which hides the complexity as described above and translates the
callbacks to the following more functional callbacks:
added; called when the service required has become available.
swapped; called when the service required needs to be replaced due to add or
removal of an aspect. This to be sure the component uses the aspect that's on
top of the aspect chain for the required service.
changed; called when the service properties of an added required service have
changed.
removed; called when the service required has become unavailable.
With these callbacks a developer does not have to worry about the possible
sequences in which added/removed can occur.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
