[
https://issues.apache.org/jira/browse/FELIX-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703049#action_12703049
]
Felix Meschberger commented on FELIX-993:
-----------------------------------------
Committed a fix in Rev. 768910. See comment [1] in FELIX-1053 for details.
[1]
https://issues.apache.org/jira/browse/FELIX-1053?focusedCommentId=12703047&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12703047
> Reference target filters not handled correctly
> ----------------------------------------------
>
> Key: FELIX-993
> URL: https://issues.apache.org/jira/browse/FELIX-993
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.0.6
> Reporter: Soren Petersen
> Assignee: Felix Meschberger
> Fix For: scr-1.0.8
>
> Attachments: DependencyManager.patch
>
>
> The SCR implementation does not handle references with target filter
> correctly. When the properties of a bound service is modified so that the
> service no longer matches the reference filter it isn't unbound as it should.
> Suppose we have an event broadcaster component defined by:
> <component name="EventBroadcaster">
> <implementation class="example.EventBroadcaster" />
> <reference
> name="eventListeners"
> interface="example.EventListener"
> cardinality="0..n"
> policy="dynamic"
> bind="addListener"
> unbind="removeListener"
> target="(listener.state=Active)"
> />
> </component>
> If an event listener is registered by the code
> Dictionary<String, Object> props = new Hashtable<String, Object>();
> props.put("listener.state", "Active");
> ServiceRegistration reg =
> context.registerService(EventListener.class.getName(), new EventListener(),
> props);
> the new service will be bound to our event broadcaster and the addListener
> method will be called. This is as it should be. Now, suppose we changed the
> properties of the service by executing
> Dictionary<String, Object> props2 = new Hashtable<String, Object>();
> props2.put("listener.state", "Inactive");
> reg.setProperties(props2);
> At this point, the event listener service should be unbound from the event
> broadcaster component since it does no longer match the target filter.
> However, due to a bug in org.apache.felix.scr.impl.DependencyManager, this
> the service stays bound and isn't even unbound if
> reg.unregister();
> is executed.
> The problem is, basically, caused by the following two segments of code:
> public void serviceChanged( ServiceEvent event )
> {
> switch ( event.getType() )
> {
> case ServiceEvent.REGISTERED:
> serviceAdded( event.getServiceReference() );
> break;
> case ServiceEvent.MODIFIED:
> serviceRemoved( event.getServiceReference() );
> serviceAdded( event.getServiceReference() );
> break;
> case ServiceEvent.UNREGISTERING:
> serviceRemoved( event.getServiceReference() );
> break;
> }
> }
> and
> private void serviceRemoved( ServiceReference reference )
> {
> // ignore the service, if it does not match the target filter
> if ( !targetFilterMatch( reference ) )
> {
> [...]
> return;
> }
> [...]
> }
> Since the properties of the service has already been modified when
> serviceChanged is called, the filter will no longer match the service and
> serviceRemoved will ignore it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
