[
https://issues.apache.org/jira/browse/FELIX-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778116#action_12778116
]
Felix Meschberger commented on FELIX-1866:
------------------------------------------
> -> 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.
> 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/[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.
