|> I hope I'm not being really stupid here. Couldn't you have one master |class |> loader that delegated to a UCL. Then you wouldn't need all this funky |> locking and hacks and workarounds. Switch the ULR and UCL. ULR delegate |to |> UCL instead of the other way around.... |> |> Again, maybe I'm just ignorant of the code.
we do that already, the URL delegates to UCLs. Where the loading thread originates is the problem. the way CL work is that the defining cl gets asks for refering classes (afaicr) so if a class refers to another class, was really defined by a given CL then an encompassing master cl that delegates would not be asked for the class but that first UCL would, you are back in UCL going to ULR and back to UCL which is how we do today, we DO have the point of control in that central place so we can monothread when we want as scott says. I will look at it this weekend. I like the idea of ONE classloader that is just a proxy to UCL and that CL is associated with the thread but I am pretty sure it doesn't work that way, you ask your defining CL not the context CL at the VM level. I could be wrong marcf |> |> Bill |> | | | |_______________________________________________________________ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
