[
https://issues.apache.org/jira/browse/FELIX-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed FELIX-4000.
-------------------------------
> [DS] ConcurrentModificationException in AbstractComponentManager iterating
> through m_dependencyManagers
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-4000
> URL: https://issues.apache.org/jira/browse/FELIX-4000
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.8.0
> Reporter: David Jencks
> Assignee: David Jencks
> Fix For: scr-1.8.0
>
>
> java.util.ConcurrentModificationException
> at
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.updateTargets(AbstractComponentManager.java:1002)
> at
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:580)
> at
> org.apache.felix.scr.impl.config.ImmediateComponentHolder.configurationDeleted(ImmediateComponentHolder.java:249)
> at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:232)
> m_dependencyManagers is initialized in the constructor and the only other
> place it changes is in clear() where it's cleared. My first idea is to just
> not try to help the GC and not actually clear the m_dependencyManagers list.
> Otherwise we'll have to add a lot of locking to make sure that no threads
> disable the component while any other thread is doing anything.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
