No, there has been no indication that this will be fixed.
There was some additional simplification in 3.2.5 and 3.2.6 that further reduced the CCE problem, but there are still scenarios where it can occur. The workaround in that case is to simply preload the classes to avoid multiple threads trying to define the same classes.
Thanks for the reply. Given that there is still a problem here, do you feel that the suggested workaround should be put somewhere in your official documentation (i.e. provide some recommended ways to preload all your classes...)?
It seems to me that Sun has two problems:
1) They lock class loaders before even calling into loadClassInternal, thereby making it impossible for class loading schemes (like UCL/ULR) to lock on some higher level object.
2) That they're detecting CCE based on the assumption that the CL that they locked is never released during the load.
You guys obviously know all this, so I'm wondering if you have at least given thought to providing an alternative CL loading scheme (i.e. one that would trade the UCL flexibility for parent-delegation stability)? I understand the rationale behind the UCL scheme and if it weren't for the 2 issues above, I would have no problem with it. I also agree that the *real* bug here is in Sun's court. Meanwhile however, users of your app server will suffer from these random CCE issues with their only recourse being to "load all classes at startup" (which itself isn't garaunteed to work, as the problem could theoretically happen during a re-deployment scenario...). Maybe the suggested workaround should be to have a deployment options that loads all classes synchronously when a UCL is first created or a URL is added to a given UCL.
FWIW, we've actually chosen a different approach as a workaround to this problem.
(Note: I know this is a big time compromise and a bit of a hack!)
I modified some of the UCL classes to optionally create "root" classloader that each of the UCL instances set as their parent and which point at all the URLs that all of the UCLs point at. Then all classloading is done though this "root" classloader. This behavior is enabled/disabled through a system property. Now, this obviously makes things like CL isolation and re-deployment break as the root CL becomes essentially a single monolithic CL that loads everything. For our particular usage this was ok, but it is definitely not a general solution for everyone.
You are free to replace the UnifiedLoader implementation with whatever you want using the jboss jmx system properties. Its planned to provide a more traditional parent/child class loading implementation in the not too distant future.