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/ 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]> wrote:
Cheers, Steven Harris Director of Engineering [EMAIL PROTECTED] 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] 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] 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] 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 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] 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
