On 18 Sep, David Jencks wrote: > 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.
Ok. Just seams a little waird to deploy server components inside emtry sars. But ok, that is maybe the way to go. I will starts looking into 3.2 when I have finalized som more of my stuff. ulr - what is that? ;-) > >> >> 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. ? I guess it will work out of the box with the Heir..Rep, since classes are loaded locally firts. >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? Yea I know, which is part of my disapointment. I reallt thought that hod deploy of server components would solve the hazzle of beeing forced to have all your custom libs in lib/ext and overwriting jboss system libs and restarting the server. In the 2.4 line you do not just install JBoss, you have to install your application with a specific JBoss ;-). > Which library are you having problems with in > particular? In this case its concurrent.jar, but I have not yet checked which version is which. I see it mostly as a symptom. Thanks //Peter > > 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 -- ------------------------------------------------------------ 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
