Hi, i am sorry if I have slept under a stone the last 6 month or so, but I have to say I find the new classloader aproach somewhat frustrating (if I am not wrong in what follows).
At least in 3.0 the following scenario (among others) would apply: Say we wanted to integrate two system services (as mbeans). a) Both uses a common library, but of differents versions. b) Both uses a lib that also JBoss uses, but of later version. What happens in this case with the current CL aproach, well. b) is impossible if you do not change the lib used by JBoss (speek about cost of integration to verify that that works). a) is stocastic. The Mbean getting deployed first will rule wich classes are loaded and cached globaly. As far as I have found out the only type that do not have this problem is *.ear when used with the Heir...Repository. But no other packages types has this option. Would it not be good to, either 1) Have the same optional Heir..Rep for at least SAR modules, so they can load local classes that are different from global ones. or 2) Change the loading algoritms so its looks something like this: - Check cache connected to classloader - Check local classloader (cache localy, and globaly if its not there) - Check global cache - Check global repository The later does, however, not fully solve the problem with dependant jars embedded in a sar, since - if I understand it correctly - they are loaded as equal sitizens of the global repository. Here I guess only the HeirarchicalLoaderRepository2 is a solution (but with that aproach classes will not become available globaly, only in the Heir...Rep). Or have I gone completely nuts? //Peter -- ------------------------------------------------------------ Peter Antman Chief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ------------------------------------------------------------ ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
