[
https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Offermans resolved FELIX-3201.
-------------------------------------
Resolution: Fixed
Reviewed and committed both patches.
> 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
> Assignee: Marcel Offermans
> Labels: features
> Attachments: dm-core-patch.txt, dm-test-patch.txt
>
>
> 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
