Felix
  1. Felix
  2. FELIX-1866

SCR 1.1 restarts components when service properties are changed, even if "modified" attributed is specified

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: scr-1.2.0
    • Fix Version/s: scr-1.4.0
    • Labels:
      None
    • Environment:
      linux, jdk1.5

      Description

      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

        Issue Links

          Activity

          Hide
          Felix Meschberger added a comment -

          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 ?

          Show
          Felix Meschberger added a comment - 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 ?
          Hide
          Pierre De Rop added a comment -

          Thanks for your explanation, Felix.

          -> I tested with latest CM from the trunk, and I don't have the CM exception anymore.
          Indeed, it seems that this issue is really related to the 1841 one (should I close it ?)

          -> So, I modified the SCR descriptor of the english dictionary, in order to make it an immediate component, instead of a delayed component: and the dictionary is not deactivated/reactivated anymore: it is just invoked in its "updated" callack as expected, when I modify the properties using CM.

          -> However, I noticed that the other component which is depending on the dictionary is re-bound with it (once I update the dictionary service). And what I don't understand is that all my dictionary properties start with a dot ("."), meaning that they should not be propagated to the published dictionary service.
          So, why is the dictionary re-bound to the other component ?
          in fact, all I would like to do is to modify the EnglishDictionary (private) service properties, without causing any re-activatation, or any re-bind ... do you think it's possible to do such a thing ?

          thanks;
          /pierre

          Show
          Pierre De Rop added a comment - Thanks for your explanation, Felix. -> I tested with latest CM from the trunk, and I don't have the CM exception anymore. Indeed, it seems that this issue is really related to the 1841 one (should I close it ?) -> So, I modified the SCR descriptor of the english dictionary, in order to make it an immediate component, instead of a delayed component: and the dictionary is not deactivated/reactivated anymore: it is just invoked in its "updated" callack as expected, when I modify the properties using CM. -> However, I noticed that the other component which is depending on the dictionary is re-bound with it (once I update the dictionary service). And what I don't understand is that all my dictionary properties start with a dot ("."), meaning that they should not be propagated to the published dictionary service. So, why is the dictionary re-bound to the other component ? in fact, all I would like to do is to modify the EnglishDictionary (private) service properties, without causing any re-activatation, or any re-bind ... do you think it's possible to do such a thing ? thanks; /pierre
          Hide
          Felix Meschberger added a comment -

          > -> I tested with latest CM from the trunk, and I don't have the CM exception anymore.
          > Indeed, it seems that this issue is really related to the 1841 one (should I close it ?)

          Ehrm, no the CM issue is related to FELIX-1727 which is already resolved.

          > -> However, I noticed that the other component which is depending on the dictionary is re-bound with it (once I update the dictionary
          > service). And what I don't understand is that all my dictionary properties start with a dot ("."), meaning that they should not be
          > propagated to the published dictionary service.

          SCR currently does not check whether there is really a modification in the service registration properties or not. It just regenerates the dictionary making up the service registration properties and calls the ServiceRegistration.setProperties method. This causes the service changed event to be sent.

          As an optimization SCR could of course verify whether the service registration properties really change as a consequence of the configuration update.

          WDYT ?

          > So, why is the dictionary re-bound to the other component ?

          That is probably the consequence of FELIX-1841: where the component is unbound and rebound on service modification.

          Show
          Felix Meschberger added a comment - > -> I tested with latest CM from the trunk, and I don't have the CM exception anymore. > Indeed, it seems that this issue is really related to the 1841 one (should I close it ?) Ehrm, no the CM issue is related to FELIX-1727 which is already resolved. > -> However, I noticed that the other component which is depending on the dictionary is re-bound with it (once I update the dictionary > service). And what I don't understand is that all my dictionary properties start with a dot ("."), meaning that they should not be > propagated to the published dictionary service. SCR currently does not check whether there is really a modification in the service registration properties or not. It just regenerates the dictionary making up the service registration properties and calls the ServiceRegistration.setProperties method. This causes the service changed event to be sent. As an optimization SCR could of course verify whether the service registration properties really change as a consequence of the configuration update. WDYT ? > So, why is the dictionary re-bound to the other component ? That is probably the consequence of FELIX-1841 : where the component is unbound and rebound on service modification.
          Hide
          Felix Meschberger added a comment -

          Added a proposed patch to FELIX-1841. You might want to test (applied to trunk; my proposed patch does not include your proposed patch).

          Show
          Felix Meschberger added a comment - Added a proposed patch to FELIX-1841 . You might want to test (applied to trunk; my proposed patch does not include your proposed patch).
          Hide
          Pierre De Rop added a comment -

          I verified the fix and it works fine.

          thanks Felix

          Show
          Pierre De Rop added a comment - I verified the fix and it works fine. thanks Felix

            People

            • Assignee:
              Felix Meschberger
              Reporter:
              Pierre De Rop
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development