Eric, Terracotta is using "named classloaders" to assign identity to arbitrary class loaders in JVM, so it could tell what classloader been used to load each class. I don't think it is related to the issue classwords trying to solve.
regards, Eugene Eric Redmond wrote: > If you are looking for a mature, full-featured named classloader (and > more), consider Classworlds. It used to be here, where you can read a > little about it: > > http://classworlds.codehaus.org/ <http://classworlds.codehaus.org/> > > but is now buried into the core of Plexus... but can still be used as > a stand-alone project. > > Eric > > On 5/22/07, *Steven Harris* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > Cheers, > Steven Harris > > Director of Engineering > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > www.terracotta.org <http://www.terracotta.org> > > > > On May 22, 2007, at 3:04 PM, Geert Bevin wrote: > >>> Good question. If someone were to serialize that graph and >>> de-serialize it. >>> Is that case handled? >> >> Afaik, this isn't automatically handled through serialization. >> >> >>> If it isn't, can we at least cover a wider subset of the world >>> without naming classloaders? >>> With web apps for instance? If not, what we would need to make >>> things simpler. >> >> I sort of fear that this might be something that is different on >> a case-by-case basis. Very dependent on the applications and >> frameworks. > > I'll bet we can come up with some default mode that handles a nice > swath of the world and then rely on named classloaders for the rest. > but that is just a theory at this point. > > >> >>> Would be nice to be able to alias classloader names in config to >>> make it easier to share >>> objects between say tomcat and a swing app? >> >> I agree that this could be nice, but wouldn't it make the whole >> thing even more complex, ie. another concept to understand: >> "aliased named classloaders"? > > For the people who need this the only other option is to do it > manually which is a big pain. For everyone else, they would never > know the concept exists. > > Just being able to make classloader names equivalent between nodes > would remove a whole bunch of ugly code in cross appserver and > cross classloader > architecture worlds. We should probably pick some use cases. i.e . > osgi, tomcat to swing, etc. Look at them one at a time and figure > out how to best balance > out form over function. > >> >>> >>> >>> Cheers, >>> Steven Harris >>> >>> Director of Engineering >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> www.terracotta.org <http://www.terracotta.org> >>> >>> >>> >>> On May 22, 2007, at 2:52 PM, Geert Bevin wrote: >>> >>>> 1. object X instantiates an object Y by loading the class >>>> explicitly through another classloader >>>> 2. object Y is stored into object Z >>>> 3. object Z is shared >>>> >>>> How can object Z on another node know which classloader has to >>>> be used for object Y's class? >>>> >>>> On 22 May 2007, at 23:48, Steven Harris wrote: >>>> >>>>> I believe so. Question in my mind is, why can't we do the same. >>>>> >>>>> >>>>> Cheers, >>>>> Steven Harris >>>>> >>>>> Director of Engineering >>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>> www.terracotta.org <http://www.terracotta.org> >>>>> >>>>> >>>>> >>>>> On May 22, 2007, at 2:46 PM, Geert Bevin wrote: >>>>> >>>>>> Doesn't serialization just use the caller's current classloader? >>>>>> >>>>>> On 22 May 2007, at 23:42, Steven Harris wrote: >>>>>> >>>>>>> I think we can follow the same rules that serialization follow >>>>>>> about choosing classloaders but I'm not sure. >>>>>>> >>>>>>> Cheers, >>>>>>> Steven Harris >>>>>>> >>>>>>> Director of Engineering >>>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>> www.terracotta.org <http://www.terracotta.org> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 22, 2007, at 2:38 PM, Geert Bevin wrote: >>>>>>> >>>>>>>> What about classes that are loaded through another classloader >>>>>>>> (ie. an application having several classloaders). How well >>>>>>>> TC be >>>>>>>> able to automatically tell which classloader it has to >>>>>>>> retrieve it >>>>>>>> from, if it isn't named? >>>>>>>> >>>>>>>> On 22 May 2007, at 23:22, Steven Harris wrote: >>>>>>>> >>>>>>>>> This is something that has come up a few times over the >>>>>>>>> last few >>>>>>>>> years. Alex mentioned a solution and gkeim mentioned a similar >>>>>>>>> solution. >>>>>>>>> I want to schedule a brain storming session on it in the >>>>>>>>> coming >>>>>>>>> weeks >>>>>>>>> but... >>>>>>>>> >>>>>>>>> Since I don't believe we ever push objects to a client >>>>>>>>> anymore, at >>>>>>>>> least not all the way to instantiation, I believe we can >>>>>>>>> just use >>>>>>>>> the >>>>>>>>> classloader of requesting client. This may not >>>>>>>>> have always been true but I think it is true now. What reasons >>>>>>>>> can we >>>>>>>>> think of that would require us to need named classloaders >>>>>>>>> anymore? >> >> -- >> Geert Bevin >> Terracotta - http://www.terracotta.org <http://www.terracotta.org> >> Uwyn "Use what you need" - http://uwyn.com >> RIFE Java application framework - http://rifers.org >> Music and words - http://gbevin.com >> >> > > > _______________________________________________ > tc-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > > -- > Eric Redmond > http://www.sonatype.com > ------------------------------------------------------------------------ > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
