[
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabian Lange updated KARAF-3798:
--------------------------------
Description:
This error happens pretty frequently with M3, when there are multiple features
installed on startup and config files to activate them created.
{code}
2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
| 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem
delivering configuration event to [org.osgi.service.cm.ConfigurationListener,
id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
java.lang.NullPointerException
at
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}
As written in latest comment, the root cause seems to be that multiple
installFeature calls to FeatureService mess up the state of the bundles. In my
case it left a bundle in a corrupt state, which was noticed when the
configuration change did not really activate the service.
was:
This error happens pretty frequently with M3, when there is a config file
created directly after startup. I tried to look how scr is implemented, but
everything newer than 1.8.2 seems to be a mess in git.
{code}
2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
| 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem
delivering configuration event to [org.osgi.service.cm.ConfigurationListener,
id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
java.lang.NullPointerException
at
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}
> FeaturesServiceImpl not threadsafe
> ----------------------------------
>
> Key: KARAF-3798
> URL: https://issues.apache.org/jira/browse/KARAF-3798
> Project: Karaf
> Issue Type: Bug
> Reporter: Fabian Lange
>
> This error happens pretty frequently with M3, when there are multiple
> features installed on startup and config files to activate them created.
> {code}
> 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
> | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem
> delivering configuration event to [org.osgi.service.cm.ConfigurationListener,
> id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
> java.lang.NullPointerException
> at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
> {code}
> As written in latest comment, the root cause seems to be that multiple
> installFeature calls to FeatureService mess up the state of the bundles. In
> my case it left a bundle in a corrupt state, which was noticed when the
> configuration change did not really activate the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
