[
https://issues.apache.org/jira/browse/FELIX-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-993.
-------------------------------------
Resolution: Fixed
Fix Version/s: scr-1.0.8
Thanks for reporting the issue and providing a patch.
In Rev. 766654 I have just removed the test for the target filter: You remark
correctly, that the target filter match might return a false negative. But
since the check for whether the service is actually bound/used or not takes
place anyway (next check after decrementing the counter), your replacement
check is not actually required.
Please close this issue, if this works for you. Thanks.
> 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.
