> 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.

> 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"?

>
>
> 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

Reply via email to