felix-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/FELIX-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Xander Uiterlinden updated FELIX-3201:
--------------------------------------

    Attachment: dm-test-patch.txt
                dm-core-patch.txt

Attached a both a patch to the ServiceDependency, ServiceUtil and ServiceDependencyImpl which
implements the improvement described.
It also includes a test case.
                
> 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
>              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

        

Mime
View raw message