My impression from the problemAgain stacktrace is that there was indeed a
change in behaviour:
Thread1 does call
java.lang.ClassLoader.loadClassInternal() [instance CL1, no lock
obtained]
org.jboss.system.ServiceLibraries.loadClass() [instance SL1, no lock
obtained]
org.jboss.system.URLCLassLoader.loadClassLocally() [instance CL1, no
lock obtained]
java.lang.ClassLoader.loadClass() [instance CL1, lock on CL1
obtained]
[now the class is loaded, and additional linkage happens, some other
class is needed]
Thread2 does
java.lang.ClassLoader.loadClassInternal() [instance CL2, no lock
obtained]
org.jboss.system.ServiceLibraries.loadClass() [instance SL1, no lock
obtained]
org.jboss.system.URLCLassLoader.loadClassLocally() [instance CL2, no
lock obtained, failed]
[now the SL1 code obains the SL1.classLoaders lock]
Thread1 does now
java.lang.ClassLoader.loadClassInternal() [instance CL1, lock on CL1
obtained]
org.jboss.system.ServiceLibraries.loadClass() [instance SL1, lock on
CL1 obtained]
[SL1 waits on the SL1.classLoaders lock, has lock on CL1]
Thread2 does now
org.jboss.system.URLClassLoader.loadClassLocally() [instance CL1,
lock on SL1 obtained]
java.lang.ClassLoader.loadClass() [instance CL1, has lock on SL1
waits for lock on CL1]
Oles changes to the ServiceLibrary should perhaps (in addition to the NOT
applied patch) now lead to a successful result (Ole, when you say no
deadlocks anymore does that mean without or WITHOUT the patch? ;-)
CGJ
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
