[
https://issues.apache.org/jira/browse/FELIX-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-1866:
-------------------------------------
Fix Version/s: scr-1.2.2
> 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
> Fix For: scr-1.2.2
>
>
> Hi everyone,
> This issue is described here:
> http://www.mail-archive.com/[email protected]/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.
