| Summary: | ConcurrentModificationException while generating JAXB classes | ||
|---|---|---|---|
| Product: | [WebTools] Dali JPA Tools | Reporter: | Neil Hauge <neil.hauge> |
| Component: | General | Assignee: | Karen Butzke <karenfbutzke> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | brian.vosburgh, jolene.moffitt, karenfbutzke, paul.fullbright |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Neil Hauge
This is a case where a Hashtable is needed as opposed to the HashMap that is being used. (In reply to comment #1) > This is a case where a Hashtable is needed as opposed to the HashMap that is > being used. This statement was a bit simplistic. After saying this, I'm not sure that Hashtable's synchronized nature would actually prevent a concurrent mod exception in this case, depending on how the collection was modified. ConcurrentHashMap would likely be a better option if we were moving the BREE to 1.6, but for now we wish to keep it at 1.5 for this plugin. Brian reminded me that this issue is specifically related to the collection.toArray() that is being performed in the CloneIterator constructor, which is not a syncronized collection of values in the case of the HashMap, but would be in the case of a Hashtable, since Hashtable.values() would return a SyncronizedCollection. As a result, the use of a Hashtable in this case should in fact prevent this particular problem from occurring. See AbstractJaxbContextRoot 'packages' as the Map in question. GenericJavaClassMapping 'includedAttributesContainers' is a HashMap as well fixed in HEAD Verified in Build S-3.1.0-20111117042513 Verified when you import large schemas exceptions do not occur. See the link to view test steps for verification. http://wiki.eclipse.org/Dali_3.1_RC1 |