felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xander Uiterlinden (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-3201) Offer more functional callback methods for services that have aspects on them.
Date Fri, 04 Nov 2011 13:01:00 GMT
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)

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


View raw message