Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <454542236.1258292439639.JavaMail.jira@brutus>
Date: Sun, 15 Nov 2009 13:40:39 +0000 (UTC)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-1866) SCR 1.1 restarts components when
 service properties are changed, even if "modified" attributed is specified
In-Reply-To: <558339425.1258190559699.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778100#action_12778100 ] 

Felix Meschberger commented on FELIX-1866:
------------------------------------------

Thanks for reporting the issue.

The simple one first: It is a kown issue with our configadmin implementation, that leading dots in the rleeased version are not allowed. This has been fixed in trunk. See FELIX-1727 for details.

Now, for the more complicated issue: It looks like this is related to FELIX-1841.

I interpret from the stacktrace and your setup:

The property modification causes the service properties to be updated and thus a service changed event being fired. In another component referring to the dictionary component this event is caught and causes a rebind of the service (service unbind/check/bind).

Now, since the component is a delayed component, it has to be deactivated if no more references exist to it (which seems to be the case here). Hence the component is deactivated due to the unbind caused by the service changed event.

After the other component ensured it still needs the service, it binds to it again, causing SCR to instantiate (and thus activate) the component again.

If this interpretation is correct, this issue caused by the same "problem" as underlying FELIX-1841 in that the reference is unbound and rebound while checking for the target.

WDYT ?

> SCR 1.1 restarts components when service properties are changed, even if "modified" attributed is specified
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-1866
>                 URL: https://issues.apache.org/jira/browse/FELIX-1866
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.2.0
>         Environment: linux, jdk1.5
>            Reporter: Pierre De Rop
>
> Hi everyone,
> This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13733.html
> I'm using the following xml descriptor in order to be notified when a service configuration property is modified from CM (I use the modify attribute):
> <?xml version="1.0" encoding="utf-8"?>
> <components xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
>   <scr:component name="englishdico" modified="updated" configuration-policy="require">
>     <service>
>       <provide interface="com.alcatel_lucent.dictionary.DictionaryService"/>
>     </service>
>     <property name="Language" value="en"/>
>     <implementation class="com.alcatel_lucent.dictionary.english.EnglishDictionary" />
>   </scr:component>
> </components>
> I also use CM 1.2.4 and when I programatically re-configure my "EnglishDictionary" component like this:
> class Updater {
>   ConfigurationAdmin _cm;
>   void update(String pid, Dictionary update) {
>      Configuration conf = _cm.getConfiguration(pid, null);
>      if (config.getBundleLocation() != null)
>      {
>         config.setBundleLocation(null);
>      }
>      config.update(update);
>    }
> }
> Then my EnglishDictionary is properly invoked in its "updated" method (because I have configured a "modified" attribute).
> But ... the EnglishDictionary is deactivated and then reactivated.
> Is it a normal behavior or a bug ?
> I provide here the stacktrace, when the component is deactivated. may be it will help:
> at com.alcatel_lucent.dictionary.english.EnglishDictionary.deactivate(EnglishDictionary.java:20)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213)
>     at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
>     at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542)
>     at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434)
>     at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138)
>     at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:259)
>     at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:134)
>     at org.apache.felix.scr.impl.manager.DelayedComponentManager.deleteComponent(DelayedComponentManager.java:66)
>     at org.apache.felix.scr.impl.manager.AbstractComponentManager$Active.ungetService(AbstractComponentManager.java:1094)
>     at org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService(DelayedComponentManager.java:100)
>     at org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:346)
>     at org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:259)
>     at org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.java:401)
>     at org.apache.felix.framework.Felix.ungetService(Felix.java:2888)
>     at org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:370)
>     at org.apache.felix.scr.impl.manager.DependencyManager.ungetService(DependencyManager.java:759)
>     at org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:390)
>     at org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:177)
>     at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>     at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>     at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>     at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3587)
>     at org.apache.felix.framework.Felix.access$000(Felix.java:40)
>     at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:625)
>     at org.apache.felix.framework.ServiceRegistry.servicePropertiesModified(ServiceRegistry.java:505)
>     at org.apache.felix.framework.ServiceRegistrationImpl.setProperties(ServiceRegistrationImpl.java:116)
>     at org.apache.felix.scr.impl.manager.ImmediateComponentManager.modify(ImmediateComponentManager.java:472)
>     at org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:401)
>     at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationUpdated(ConfiguredComponentHolder.java:187)
>     at org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:173)
>     at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1693)
>     at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> -> I am wondering if the service is re-activated just because the service configuration is re-propagated in the published service properties ?
> -> I have also noticed that now, with DS 1.1, properties which are prefixed with a dot (".") are not supposed to be propagated in the published service properties.
> Indeed, in the spec, I see the following, page 331, in chapter 112.11:
>     "SCR must follow the recommendations of Property Propagation on page
>     86 and not propagate properties whose names start with '.' to service properties"
> So, I prefixed my english dictionary property with a ".", and I then invoked the org.osgi.service.cm.Configuration.update(Dictionary method), just to see if it resolved the problem,
> but I came across another exception. However, this exception comes from CM (I use CM 1.2.4 release):
> Throwable
> java.lang.IllegalArgumentException: Key [.englishdico.jdbcURL] must not start or end with a dot
>     at org.apache.felix.cm.impl.CaseInsensitiveDictionary.checkKey(CaseInsensitiveDictionary.java:265)
>     at org.apache.felix.cm.impl.CaseInsensitiveDictionary. (CaseInsensitiveDictionary.java:72)
>     at org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:278)
>     at org.apache.felix.cm.impl.ConfigurationAdapter.update(ConfigurationAdapter.java:110)
>     at com.alcatel.as.service.config.impl.fc.OsgiConfigurationAdmin$Conf.update(OsgiConfigurationAdmin.java:237)
>     at com.alcatel.as.service.config.impl.fc.OsgiConfigurationAdmin$Conf.update(OsgiConfigurationAdmin.java:214)
>     at com.alcatel.as.service.config.impl.fc.OsgiConfigurationAdmin$Conf.access$000(OsgiConfigurationAdmin.java:166)
>     at com.alcatel.as.service.config.impl.fc.OsgiConfigurationAdmin.configure(OsgiConfigurationAdmin.java:126)
>     at com.alcatel.as.service.config.impl.fc.FastCacheConfig.init2(FastCacheConfig.java:262)
>     at com.alcatel.as.service.config.impl.fc.FastCacheConfig.proxyAppPropertiesUpdated(FastCacheConfig.java:290)
>     at com.nextenso.mgmt.reporter.ProxyAppReporter$FastCacheListeningThread.run(ProxyAppReporter.java:180)
> Did I make something wrong at all ? 
> Best Regards;
> /pierre
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.