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