Bugzilla – Full Text Bug Listing
| Summary: | ConcurrentModificationException during EMF model initialization | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Carl Anderson <ccc> | ||||
| Component: | jst.j2ee | Assignee: | Carl Anderson <ccc> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | jsholl | ||||
| Version: | 3.2 | Flags: | cbridgha:
review+
|
||||
| Target Milestone: | 3.2.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 176237 [details]
Protect the initializePackageContents with a lock
The section of initializePackageContents() that actually modifies the EMF model needs to be made thread safe. I am doing that by introducing a common lock that must be acquired before the initializePackageContents() can modify the contents. This should prevent a ConcurrentModificationException.
Note that the patch appears to be a much larger change than it is, since the package contents initialization is moved inside of a try/catch block. The actual initialization code has not been modified. approve Committed to HEAD for WTP 3.2.2 and WTP 3.3 |
An adopter product is seeing the following exception: Caused by: java.util.ConcurrentModificationException at org.eclipse.emf.common.util.AbstractEList$EIterator.checkModCount(AbstractEList.java:762) at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:710) at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:696) at org.eclipse.emf.ecore.impl.ESuperAdapter.setFlags(ESuperAdapter.java:376) at org.eclipse.emf.ecore.impl.EClassImpl$11.setFlags(EClassImpl.java:2112) at org.eclipse.emf.ecore.impl.ESuperAdapter.notifyChanged(ESuperAdapter.java:195) at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:380) at org.eclipse.emf.common.notify.impl.NotificationImpl.dispatch(NotificationImpl.java:1033) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:367) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:345) at org.eclipse.emf.ecore.impl.EClassImpl$9.delegateAdd(EClassImpl.java:1698) at org.eclipse.emf.ecore.impl.EClassImpl$9.delegateAdd(EClassImpl.java:1) at org.eclipse.emf.common.util.DelegatingEList.addUnique(DelegatingEList.java:340) at org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl.doAddUnique(DelegatingNotifyingListImpl.java:385) at org.eclipse.emf.common.notify.impl.DelegatingNotifyingListImpl.addUnique(DelegatingNotifyingListImpl.java:281) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307) at org.eclipse.jst.j2ee.common.internal.impl.CommonPackageImpl.initializePackageContents(CommonPackageImpl.java:1356) at org.eclipse.jst.j2ee.common.internal.impl.CommonPackageImpl.init(CommonPackageImpl.java:296) at org.eclipse.jst.j2ee.common.CommonPackage.<clinit>(CommonPackage.java:243) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) ... 80 more What causes this is that an element of the PackageImpl (in this case compatibilityDescriptionGroupEClass) is being updated in one package (in this case the CommonPackage) in initializePackageContents() while that same element is modified in another package's initializePackageContents() on another thread.