[ 
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.

Reply via email to