On 2002.09.18 09:33:40 -0400 Peter Antman wrote: > 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.
I set up the ulr stuff in 3.2 so it would be really easy to extend to other module types. Go ahead if you would like it for sars. In 3.0 branch it is a little harder. I didn't feel really pressed to do this since you can put any kind of package you want in an .ear and get the same effect. > > 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). I think this is apt to cause more problems than it solves. To solve the "I want a different version of a lib used internally by jboss" you'd have to find a way of making that part of jboss use a non-default hier.loader repository. This is presumably possible but sounds like a big hassle, in particular to maintain and test continually. In this case, didn't we have the same problem in 2.4? Which library are you having problems with in particular? thanks david jencks > > > 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 > > ------------------------------------------------------- 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
