[
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/[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.
