[ 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