Scott,
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.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861448#3861448
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861448
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
