On 2002.09.18 10:28:19 -0400 Peter Antman wrote: > 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 agree, but at least there is some way to do it. > > I will starts looking into 3.2 when I have finalized som more of my > stuff. ulr - what is that? ;-) unified loader repository. I should have said loader repository. > > > >> > >> 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. (I think) the jars in lib rather than server/[conf]/lib are not going to be versionable since they are used in jboss startup to set up the versioning mechanism. Stuff in server/[conf]/lib should be versionable by deploying it in a .sar, although you may have problems with deployment order. I wasn't aware that there had been any changes in concurrent.jar for years... can you provide details, we should probably upgrade. thanks david jencks > > 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 > > ------------------------------------------------------- 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
