Return-Path: 
 <dev-return-13710-apmail-felix-dev-archive=felix.apache.org@felix.apache.org>
Delivered-To: apmail-felix-dev-archive@www.apache.org
Received: (qmail 90058 invoked from network); 19 Mar 2009 16:02:14 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 19 Mar 2009 16:02:14 -0000
Received: (qmail 71529 invoked by uid 500); 19 Mar 2009 16:02:13 -0000
Delivered-To: apmail-felix-dev-archive@felix.apache.org
Received: (qmail 71499 invoked by uid 500); 19 Mar 2009 16:02:13 -0000
Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@felix.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@felix.apache.org>
List-Post: <mailto:dev@felix.apache.org>
List-Id: <dev.felix.apache.org>
Reply-To: dev@felix.apache.org
Delivered-To: mailing list dev@felix.apache.org
Received: (qmail 71488 invoked by uid 99); 19 Mar 2009 16:02:13 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Mar 2009 09:02:13 -0700
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Mar 2009 16:02:12 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 9DFAD234C044
	for <dev@felix.apache.org>; Thu, 19 Mar 2009 09:01:52 -0700 (PDT)
Message-ID: <1179901109.1237478512646.JavaMail.jira@brutus>
Date: Thu, 19 Mar 2009 09:01:52 -0700 (PDT)
From: "Soren Petersen (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Created: (FELIX-993) Reference target filters not handled
 correctly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org

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


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.