They will respond that you should not tweak the classloading delegation as we do such that mutual dependencies occur ...
So we must first have a good advocate there. CGJ -----Ursprüngliche Nachricht----- Von: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 5. Oktober 2001 00:21 An: Jboss-Development (E-Mail) Betreff: RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader You can document it as a bug on Sun. If it really is, they can confirm it. Only take care of NOT SPEAKING ABOUT any imaginary patch :) > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En nombre de Jung > , Dr. Christoph > Enviado el: jueves, 04 de octubre de 2001 9:06 > Para: Jboss-Development (E-Mail) > Asunto: AW: [JBoss-dev] The rabbit has a bug in its pelt: > org.jboss.system.URLClassLoader > > > Hi Ole & others, > > IMHO, your nice patch has partly solved the problem, i.e., the issue that > Sacha was noticing with the patch.jar NOT;-) applied. And even without > patch.jar, it should have greatly diminished the deadlock > possibilities ... > But nevertheless, I could imagine a scenario, where a synchronized > java.lang.ClassLoader.loadClassInternal() would lead to hang-ups: > > ServiceLibrary contains two classloaders CL1 and CL2. > > CL1 has class C1 and needs to loadClassInternal("C2") in Thread T1. > CL2 has Class C2 and needs to loadClassInternal("C1") in Thread T2. > > Then there is certainly a constellation where both threads concurrently > enter the classloaders, obtaining the respective CL locks and the > ServiceLibrary code mutually dispatching them will block. > > Is that a valid scenario? > > CGJ > > -----Ursprüngliche Nachricht----- > Von: Ole Husgaard [mailto:[EMAIL PROTECTED]] > Gesendet: Dienstag, 2. Oktober 2001 20:30 > An: [EMAIL PROTECTED] > Betreff: Re: [JBoss-dev] The rabbit has a bug in its pelt: > org.jboss.system.URLClassLoader > > > "Jung , Dr. Christoph" wrote: > > > > I must correct myself! We have a principle problem, unfortunately, for > which > > I do not > > have an immediate answer right now: > > > > Actually, instead of synchronized(classLoaders) in > ServiceLibraries, there > > would be the need > > to *atomically* synchronize on all instances of the set in order not to > > interfere with the ClassLoader.loadClassInternally() calls. > > > > But this is not possible with the Java synchronization mechanism, AFAIK. > > Please forgive me if I am wrong - I'm not very familiar > with this code. > > But isn't the only reason for synchronizing on classLoaders > that there would be problems if another thread tries to > add or remove classloaders while the Set is traversed? > > If this is the case, couldn't we avoid synchronizing on it > by making ServiceLibraries.addClassLoader() and > removeClassloader() create an entire new Set? > > Of course, then these methods would have to be synchronized, > and we would probably also have to synchronize on the > instance variables classes, resources, clToClassSetMap and > clToResourceSetMap, but these locks would not be held > while ClassLoader.loadClassInternally() is called. > > > Best Regards, > > Ole Husgaard. > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
