Well I think maybe we can legally look at the code...
In my (unproven) opinion the problem comes from the loadClass(name,
resolve) method being synchronized and calling to another object within the
synchronization. The loadClassInternal being synchronized makes no
difference here (although I might agree it shouldn't be) since it ends up
calling the synchronized loadClass anyway.
I'm not quite sure how to reproduce the problem or make this patch idea
work... but here is a rewritten (yet strangely invisible) loadClass that
under no circumstances should you put into your java.lang.ClassLoader code.
This one releases synchronization locks before calling parents, and
reaquires it before doing anything else. Anyone want to NOT try it?
david jencks
protected Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (this)
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c != null)
{
if (resolve) {
resolveClass(c);
}
return c;
} // end of if ()
}
//we have released the lock to call out
try
{
Class c = null;
/parent isn't going to change, I think this is ok.
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClass0(name);
}
//get the lock back to use our own methods
synchronized (this)
{
if (resolve) {
resolveClass(c);
}
return c;
}
}
catch (ClassNotFoundException e)
{
// If still not found, then call findClass in order
// to find the class.
synchronized (this)
{
Class c = findClass(name);
if (resolve) {
resolveClass(c);
}
return c;
}
}
}
On 2001.10.03 10:18:21 -0400 "Jung , Dr. Christoph" wrote:
> Hi there,
>
> In order to verify whether our hypothesis about that ugly deadlocking
> behaviour of the RH classloaders is right
>
> (Sascha, Simone and Ole seem to have some serious problems in that
> direction, if I understood their postings right),
>
> could you please NOT try out the following patch.jar (the synchronized
> modifier has been removed at Class
> java.lang.ClassLoader.loadClassInternal(String), which is IMHO a totally
> uncritical) which violates the
> Sun Binary Code License!
>
> Hence, do NOT start jboss using java -Xbootclasspath/p:patch.jar ...
>
> CGJ
>
>
> <<patch.jar>>
>
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
