Scott is the best person to answer those questions. But if you can reproduce it why don't you try it with 3.2.2RC4? Also enable TRACE for org.jboss.mx.loading and post the log snippet where it goes wrong.
I do know UCL2 didn't work under certain threading situations. The idea behind UCL3 is to pass class loading tasks to the thread that owns the classloader to avoid the issue. Sun agree the way they check ClassCircularity is wrong, but haven't fixed it :-( Regards, Adrian On Thu, 2003-09-25 at 14:44, Robert Cauble wrote: > Thanks - I really appreciate the help. > > Also, is this problem something which you have worked around for 3.2.2? > (I'm still seeing it in 3.2.1.). Or is this something which can't be > solved until Sun fixes their stuff? > > I noticed that there is a UnifiedClassLoader2 which looks like it solved > the original deadlock problem by locking the UnifiedLoaderRepository > from the loadClass method. It also looks like it didn't have the > ClassCircularityError issue that UnifiedClassLoader3 has (since it never > relinquishes the ClassLoader lock via a call to wait). What was wrong > with this approach such that you switched to UnifiedClassLoader3? > > Thanks, > Rob > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:jboss-user- > > [EMAIL PROTECTED] On Behalf Of Adrian Brock > > Sent: Wednesday, September 24, 2003 2:05 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-user] Re:[JBoss-user]ClassCircularityError- > > QueuedPessimisticEJBLock$TxLock > > > > On Wed, 2003-09-24 at 19:54, Robert Cauble wrote: > > > > Multiple classloaders is more restrictive when it comes to > > > > the security model. Classes in the same package cannot access > > > > package private methods if the classes are in different > classloaders. > > > > > > Got it. Thanks. > > > > > > > > > > You can also get errors when instances of the same class name > > > > but different class objects are passed between classloaders. > > > > > > Can you give me an example? Is this something which the JVM can't > > > handle? Or do mean that it's easy for the programmer to make a > mistake > > > if they were to do something like instantiate an object of a class > Foo > > > loaded from class loader A and then cast it to a class Foo loaded > from > > > class loader B? > > > > > > > Correct ClassCastException or the more subtle LinkageError, > > IncompatibleClassChangeError > > > > Regards, > > Adrian > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > -- > > xxxxxxxxxxxxxxxxxxxxxxxx > > Adrian Brock > > Director of Support > > Back Office > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Director of Support Back Office JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
