Hi, > I come back again with my old trick that hadn't much success > in the past. > > To solve the system class loader problem definitivly, at > least with JDK 1.4 > and upper, why not use the "java.system.class.loader" system > property (see > javadoc of java.lang.Classloader.getSystemClassLoader). > > This way, we could have a "Fake Classloader", let's call it a > "RedirectorClassLoader" (RCL), registered as the system > classloader. When a > call originates from a UCL, the RCL would do its normal work. > But when a > call doesn't come from a UCL, the RCL would check what is the current > "contextual" UCL (as we could/can have multiple UCLs) and delegate the > loading to this UCL.
Not sure if your trick works with Class.forName() in all cases, especially when to go native is some JDK class such as VersionHelper12. Class.forName goes native before calling the classloader, and there it acquires the lock on the classloader; then it delegates to the classloader, which either is a UCL(2) or a child; from the UCL you walk the hierarchy up, arriving to the system classloader (or your RCL), but we already had the chance to intercept the call at UCL level. Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). Regards, Simon ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
