felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-1866) SCR 1.1 restarts components when service properties are changed, even if "modified" attributed is specified
Date Sun, 15 Nov 2009 16:00:39 GMT

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


Mime
View raw message