[ https://issues.apache.org/jira/browse/CAMEL-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972888#action_12972888 ]
Freeman Fang edited comment on CAMEL-3442 at 12/18/10 9:37 PM: --------------------------------------------------------------- Hi Claus, I just checked the patch which I appended with CAMEL-3302, my original patch about the concern code is like + Set<ClassLoader> set = getClassLoaders(); + for (ClassLoader classLoader : set.toArray(new ClassLoader[set.size()])) { + if (!isOsgiClassloader(classLoader)) { + find(test, packageName, classLoader, classes); + } + } With this patch, there should be no ConcurrentModificationException on the Iterator. Willem revised my patch probably for better performance but introduce potential ConcurrentModificationException. @Willem Would you please re-check my patch, as classloaders set size isn't big, so change it to an array isn't a big deal IMHO, but this can avoid concurrent problem(such as ConcurrentModificationException). Another solution I can come up with is change getClassLoaders() in DefaultPackageScanClassResolver use classLoaders = Collections.synchronizedSet(new HashSet<ClassLoader>()); instead of classLoaders = new HashSet<ClassLoader>(); But this also bring in performance impact, I still prefer the way in my original patch. Best Regards Freeman was (Author: ffang): Hi Claus, I just checked the patch which I appended with CAMEL-3302, my original patch about the concern code is like + Set<ClassLoader> set = getClassLoaders(); + for (ClassLoader classLoader : set.toArray(new ClassLoader[set.size()])) { + if (!isOsgiClassloader(classLoader)) { + find(test, packageName, classLoader, classes); + } + } With this patch, there should be no ConcurrentModificationException on the Iterator. Willem revised my patch for better performance but introduce potential ConcurrentModificationException. @Willem Would you please re-check my patch, as classloaders set size isn't big, so change it to an array isn't a big deal IMHO, but this can avoid concurrent problem(such as ConcurrentModificationException). Another solution I can come up with is change getClassLoaders() in DefaultPackageScanClassResolver use classLoaders = Collections.synchronizedSet(new HashSet<ClassLoader>()); instead of classLoaders = new HashSet<ClassLoader>(); But this also bring in performance impact, I still prefer the way in my original patch. Best Regards Freeman > JBI ClassLoading issue in SMX 4.x in OsgiPackageScanClassResolver > ----------------------------------------------------------------- > > Key: CAMEL-3442 > URL: https://issues.apache.org/jira/browse/CAMEL-3442 > Project: Camel > Issue Type: Bug > Components: osgi > Affects Versions: 2.5.0 > Reporter: Claus Ibsen > Fix For: 2.6.0 > > > CAMEL-3302 introduced a fallback when using JBI in Apache ServiceMix 4.x. > However it may lead to an issue with ConcurrentModificationException when > traversing the list of classloaders. > {code} > for (ClassLoader classLoader : super.getClassLoaders()) { > if (!isOsgiClassloader(classLoader)) { > find(test, packageName, classLoader, classes); > } > } > {code} > The for loop is line 62 which causes the exception. > Issue reported here > http://camel.465427.n5.nabble.com/ServiceMix-4-Fuse-4-3-0-fuse-03-00-Problems-running-JBI-example-examples-camel-td3309088.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.